We monitor CPU cores in Zabbix and create random counters in Low-level discovery

Not so long ago there was an article about the LLD. It seemed to me boring. describes about the same as in the documentation. I decided to go further and with the help of LLD monitor those parameters that previously could not be monitored automatically, or it was quite difficult. Let us analyze the work of LLD on the example of logical processors in Windows:


Initially interested in the advanced moning besides the CPU cores and the load on the physical disks. Before the detection was introduced, these tasks were partially solved by manual addition. I added conditional disks to the zabbix_agent configuration file and generally perverted in different ways. As a result, it was very inconvenient, a lot of unpleasant manual work was added and generally it was generally wrong somehow :)
The result is a scheme that automatically detects the kernels in the system, as well as the physical disks installed in the system and adds the necessary elements of data collection. In order to learn how to implement it in yourself, welcome to cat. I will try to describe the work more or less in detail using the example of a CPU and how to do the same, but for physical disks.

Type of data sent

First of all, it is worth referring to the documentation, where he signs what LLD is and what it is eaten with. In addition to standard templates, we will be interested in the 4th section with a description of the JSON detection format. That is, we will create our own detection method. In fact, it all comes down to calling a script that generates the necessary data in the right format.
Create a script.
For the script, I chose powershell. I know him a little better than other scripting languages, and considering that everything will be spinning around WMI , it could also be done on VBS.
So, the script.
The task of the script is to determine the number of logical processors using WMI and display this data in JSON format to the console. We will transmit a variable named {#PROCNUM} , as well as its values. The output format will be approximately the same, depending on the number of logical processors:

{ "data":[ { "{#PROCNUM}":"0"}, { "{#PROCNUM}":"1"}, { "{#PROCNUM}":"2"}, { "{#PROCNUM}":"3"}, { "{#PROCNUM}":"4"}, { "{#PROCNUM}":"5"}, { "{#PROCNUM}":"6"}, { "{#PROCNUM}":"7"}, { "{#PROCNUM}":"8"}, { "{#PROCNUM}":"9"}, { "{#PROCNUM}":"10"}, { "{#PROCNUM}":"11"} ] } 

Data generation script

The script itself looks like this:

 $items = Get-WmiObject Win32_PerfFormattedData_PerfOS_Processor | select name |where-object {$_.name -ne '_Total'} write-host "{" write-host " `"data`":[" write-host foreach ($objItem in $Items) { $line = " { `"{#PROCNUM}`":`"" + $objItem.Name + "`"}," write-host $line } write-host write-host " ]" write-host "}" write-host 

Now we get that when you run the script, it will know how many cores and forms a package to send.
What are we doing next? You need to create a discovery rule .

Add low-level detection in the settings of the zabbix server

To do this, go to the desired template, which is added to the hosts that interest us, in the Discovery section and click the Create discovery rule button.

Here we see the incomprehensible value of the key: PSScript [proc.ps1] field . This is a UserParameter . This item is created for convenience, now in each new object we can simply enter the parameter in the form of the PS script name and it will search for it in a pre-specified place. The parameter itself is written in the client configuration file (usually called zabbix_agentd.conf) and looks like this:

 UserParameter=PSScript[*],powershell -File "C:\Program Files\zabbix agent\script\$1" 

We created a new detection rule with custom data collection. The request to change information is set as 1 hour. Perhaps, for such static data as the number of processors, it is too often :), but everyone is free to put his own value. For initial data collection and debugging, it is better to reduce this value to very small values ​​in order not to wait for hours to execute the script.
')

Configure prototype data

Good. We started collecting data on the number of processors. But as a result, we do not need this data, but a new item in monitoring. It is item that can collect data, not our script, our script only serves to detect the elements for data collection.
And in order to create a new data collection item derived from the LLD, in the same Discovery section, we create a new prototype. To do this, go to item prototypes and click create item prototype . I created the following collection item:


Data is collected using a standard performance counter. In zabbix, there is a perf_counter key to collect this data. Instead of the logical core number, we insert the resulting value as a variable from the Discovery section.
Now everything is ready. Or almost everything ...
From now on, when the discovery script discovers logical processors, data collection elements created for exactly this number of processors will be created for this host.
And now if we go into items for a host, the low-level detection for which has already worked, we will see that new elements have appeared:


These elements cannot be removed in a standard way, since they are created automatically, they are highlighted with a special prefix with the name of the low-level detection rule. In the screenshot it seems that some kind of garbage is written in the name :), in fact, everything is simple, I use the three-digit code in each name for sorting. That is, 100 is only a sorting number. The next digit from 0 to 11 is the logical processor number. And then already "% of the processor load". But at first it may seem that this is 0% of the CPU load and I am trying to collect this value :)

The only drawback of this whole method is that a graph, such as in the title of this post, cannot be created using a low-level detection mechanism. That is, we can, of course, create not only an item , but also a graph object for each logical processor, but we cannot create one total graph automatically with all the detected logical processors. At least I did not see how this could be done, on the zabbix forum I also could not tell. This is certainly not a particularly serious drawback, but if you have 200 hosts, this can be a problem :). After all, the schedule for each host will need to be created manually.

Monitor the performance of each physical disk in the system

In the above method it is better to understand and then it opens up ample opportunities for monitoring objects in the system, the number of which either differs from host to host or their number in everything changes during operation.
For example, it often happens that it is necessary to determine whether there was a shortage in the resources of the physical disk installed in the server. Most often, this data is difficult to catch in real-time and I want to have them collected after the fact. For this, I introduced a similar detection for physical disks to collect extensive statistics on them. And, in contrast to the processors, the elements of data collection, I created them in abundance.


Here, of course, you need to be careful, and if you have mysql on some old, crammed computer, then a similar amount will quickly take your database to heaven. Since in the above example, for each host, 20 new entries are created for each physical disk, which will create one new value per minute. On the scale of a couple of dozen servers with heaps of different disks, this translates into a more or less weighty amount of data. But then everyone is free to choose his own way samurai :)

The script for LLD physical disks looks like this:

 $items = Get-WmiObject Win32_PerfRawData_PerfDisk_PhysicalDisk | select name |where-object {$_.name -ne '_Total'} write-host "{" write-host " `"data`":[" write-host foreach ($objItem in $Items) { $line = " { `"{#DISKNUM}`":`"" + $objItem.Name + "`"}," write-host $line } write-host write-host " ]" write-host "}" write-host 

Add a new detection rule by analogy with the CPU. Similarly, we create the necessary elements in discovery .

In general, of course, this mechanism provides quite large opportunities for defining various elements for monitoring. In the same way, you can, for example, add monitoring of network interfaces, processes in the system, services and any other elements whose name and number is not known in advance.
I hope this article will help someone to deal with the LLD. I am pleased to answer your questions.