Automate monitoring: low-level detection
Monitoring a large number of devices requires automation tools to help. Otherwise, if you do everything with the mouse, you can “click” while you add and configure everything that was required. Besides, you will definitely make a mistake somewhere, man is not a robot. Fortunately, all these tools are in Zabbix: these are templates , API , discovery of network devices , auto - registration of Zabbix agents.
And from version 2.0, Low-Level Discovery (LLD) or low-level detection was added here. I would like to tell what it is.
Network Discovery (Network Discovery) is a very useful thing that allows you to avoid manually adding new network nodes and associating them with the necessary templates. What can create quite complex scenarios. For example, automatically associate a new client (its CPE) with a Wi-Fi base station with the necessary template for CPE and even automatically add this node in the right place on the map. The documentation has a good example of how network discovery is configured.
')
LLD becomes necessary in the next stage, after the node is found and attached to the template. LLD allows you to find objects of the node itself.
LLD allows us to automatically create data elements , triggers and graphics for:
You can extend the capabilities of LLD through your own scripts, as long as the output of the script for Zabbix is clear to JSON.
In addition to what LLD creates, it also regularly scans the host for changes and dynamically deletes old data elements (deleted file system) and adds new ones (inserted expansion card with additional ports).
Of course, you can do without LLD, because in all previous versions they did the same patterns. Here are just everyone who uses Zabbix, faced with the situation that there are two in one logical drive server and four in the other. That one switch has Ethernet ports 8, and the other from the same line has 24. It remains to write a 24-port pattern (4 disks), and then, after binding the device, manually disconnect unnecessary data elements, triggers. Here we are already “crowded”. And then someone made a new server, and there are 8 disks in it ... And another colleague in the existing server created another partition with a non-standard way and did not say anything ...
To understand what the LLD gives us, there is nothing better than a good example. Recall what we had to do with multiport switches in previous versions of Zabbix.
Let's say we have Cisco switches, D-Link, Zyxel and other “zoo”. With the number of ports 5/8/16/24/50.
We will monitor the state of the ports using SNMPv2 and the counters described in the IF-MIB. We don’t have LLD yet, so let's start writing a regular template. Let's call it Template_IF_MIB_SNMPV2 .
In the template for one port, we need to create 14 data elements (of course, less can be done, but we will decide that it is critically important for us to collect almost everything), as well as a number of triggers , graphs . In the Zabbix web interface, this will take about 10 minutes if you actively swing the mouse and use the “Clone” button.
After taking a breath, I don’t really want to continue for other ports. Who wants to do the same thing 50 times? Therefore, immediately there are questions:
The first problem can be solved, for example, by uploading a template to XML followed by CTRL + C / CTRL + V in a text editor. Or even write a small external script and generate XML to them. But…
But with Low-Level Discovery , we have the opportunity to make everything much easier. Instead of creating data elements for a single port, we simply create prototypes of data elements, as well as prototypes of necessary triggers ONCE. Since we only do this once, it is not at all a pity to spend time and also create informative graphs, or more precisely, prototypes of graphs, in addition.
So, to create in the LLD template, go to the detection rules :
Next, click to create a discovery rule and create a new rule, let's call it Network interfaces discovery :
We indicate everything as in the picture. Some fields are worth commenting:
So, we created a rule , now we have to create prototypes of data elements . Everything here is practically the same as when creating ordinary data elements , but there are a couple of features. For example, add inbound traffic, ifInOctets:
Description of fields:
Let's create prototypes for the remaining data elements that we need for each interface, we get something like this list:
create prototypes of triggers ...
... and chart prototypes :
By hooking our template to real network nodes, after a while we will get the result. This is how the last data for the host will look like after the LLD test:
As expected, data is collected only for active ports.
And here are the graphs, also dynamically created via LLD:
To summarize what we got, using LLD in a template for multiport switches:
But, as already mentioned, the exact same focus can be cranked with file systems and network interfaces of the computer (another example here ), as well as with many other things stored in SNMP. True, there are limitations. For example, unfortunately, the LLD will not work if the SNMP table contains several indices. It is possible to circumvent this restriction with the help of macros, however, this is already, as they say, from the category of “crutches”.
Like this. And no more fussing with similar data elements, triggers, graphs. Just set up LLD and enjoy the fruits of automation. Or configure LLD + network discovery and generally go on vacation :)
And from version 2.0, Low-Level Discovery (LLD) or low-level detection was added here. I would like to tell what it is.
Low level detection
Network Discovery (Network Discovery) is a very useful thing that allows you to avoid manually adding new network nodes and associating them with the necessary templates. What can create quite complex scenarios. For example, automatically associate a new client (its CPE) with a Wi-Fi base station with the necessary template for CPE and even automatically add this node in the right place on the map. The documentation has a good example of how network discovery is configured.
')
LLD becomes necessary in the next stage, after the node is found and attached to the template. LLD allows you to find objects of the node itself.
LLD allows us to automatically create data elements , triggers and graphics for:
- computer file systems
- computer network interfaces
- data from SNMP tables with a one-dimensional index
You can extend the capabilities of LLD through your own scripts, as long as the output of the script for Zabbix is clear to JSON.
In addition to what LLD creates, it also regularly scans the host for changes and dynamically deletes old data elements (deleted file system) and adds new ones (inserted expansion card with additional ports).
Of course, you can do without LLD, because in all previous versions they did the same patterns. Here are just everyone who uses Zabbix, faced with the situation that there are two in one logical drive server and four in the other. That one switch has Ethernet ports 8, and the other from the same line has 24. It remains to write a 24-port pattern (4 disks), and then, after binding the device, manually disconnect unnecessary data elements, triggers. Here we are already “crowded”. And then someone made a new server, and there are 8 disks in it ... And another colleague in the existing server created another partition with a non-standard way and did not say anything ...
As it was before
To understand what the LLD gives us, there is nothing better than a good example. Recall what we had to do with multiport switches in previous versions of Zabbix.
Let's say we have Cisco switches, D-Link, Zyxel and other “zoo”. With the number of ports 5/8/16/24/50.
We will monitor the state of the ports using SNMPv2 and the counters described in the IF-MIB. We don’t have LLD yet, so let's start writing a regular template. Let's call it Template_IF_MIB_SNMPV2 .
In the template for one port, we need to create 14 data elements (of course, less can be done, but we will decide that it is critically important for us to collect almost everything), as well as a number of triggers , graphs . In the Zabbix web interface, this will take about 10 minutes if you actively swing the mouse and use the “Clone” button.
After taking a breath, I don’t really want to continue for other ports. Who wants to do the same thing 50 times? Therefore, immediately there are questions:
- How to avoid wasting time creating the remaining ports (2-50)
- How to avoid requests to counters from 6 to 50 ports that are doomed to failure without manual intervention, when the universal template is attached to the 5th port switch
- How not to clutter the network with polls of port counters that are not used
The first problem can be solved, for example, by uploading a template to XML followed by CTRL + C / CTRL + V in a text editor. Or even write a small external script and generate XML to them. But…
What can be done now with LLD
But with Low-Level Discovery , we have the opportunity to make everything much easier. Instead of creating data elements for a single port, we simply create prototypes of data elements, as well as prototypes of necessary triggers ONCE. Since we only do this once, it is not at all a pity to spend time and also create informative graphs, or more precisely, prototypes of graphs, in addition.
So, to create in the LLD template, go to the detection rules :
Next, click to create a discovery rule and create a new rule, let's call it Network interfaces discovery :
We indicate everything as in the picture. Some fields are worth commenting:
| Key | snmp.discovery.v2 |
| SNMP OID | The OID that we will use for the criterion for adding the monitoring interface, in this case ifOperStatus. |
| SNMP community | This example uses the {$ COMMUNITY} macro. The same template contains the default value, {$ COMMUNITY} = public. Further, for each specific network node to which we attach this template, we can either rewrite the value of the macro, if its snmp community is different, or do nothing, and then the one written in the public template will be used. This technique helps to avoid the need to change items at the host level. |
| Filter | The value of the special macro {#SNMPVALUE}, which corresponds to the result of the ifOperStatus.X query to the device, we subject to a very complex regular expression: 1. As we know from the IF-MIB, ifOperStatus.X = 1 corresponds to up (1). Thus, we will put on monitoring only those interfaces that at the time of scanning the network were able to up (1). This will save us from collecting the counters of those interfaces that are not used. If we want to add all ports to the monitoring indiscriminately, then the filter field is simply left blank. |
| Period of preservation of lost resources | After how many days to remove the network interface from monitoring, if the network interface has ceased to be re-scanning LLD, or ifOperStatus.X status ceases to be up (1). In this case, set to zero - do not delete. |
So, we created a rule , now we have to create prototypes of data elements . Everything here is practically the same as when creating ordinary data elements , but there are a couple of features. For example, add inbound traffic, ifInOctets:
Description of fields:
| Name | if {#SNMPINDEX} ({$ PORT {#SNMPINDEX} _DESC}) In. We decipher the design. As we already know, {#SNMPINDEX} is a system macro that will correspond to the interface index in SNMP. We will substitute it in the name of the interface, for names that we understand. It will turn out: if1, if2, if3, etc. The second macro is a custom one , {$ PORT {#SNMPINDEX} _DESC}, into which name the interface index will be inserted, dynamically changing the name of the macro. It is optional, but I use it in order for Zabbix to prescribe an additional description of each interface by simply adding a macro at the host level, for example: {$ PORT1_DESC} = uplink, ISP1 |
| Key | The key must contain {#SNMPINDEX} so that the key is always unique. |
| SNMP OID | Similarly, we substitute the macro {$ SNMPINDEX} in our SNMP OID to poll the counter of the interface we need. |
create prototypes of triggers ...
... and chart prototypes :
By hooking our template to real network nodes, after a while we will get the result. This is how the last data for the host will look like after the LLD test:
As expected, data is collected only for active ports.
And here are the graphs, also dynamically created via LLD:
Total
To summarize what we got, using LLD in a template for multiport switches:
- Universal template for all devices that support IF-MIB
- Does not require additional configuration at the host level after adding the template. The maximum you need is to fill the {$ COMMUNITY} macros (if the snmp community is not public), fill in the {$ PORTx_DESC) macro (if you want to see the port description) and activate the [NET] triggers if {#SNMPINDEX} ({$ PORT { #SNMPINDEX} _DESC}) is down for key ports that require notification of status changes from up to down (which is why these triggers in the prototypes are deactivated so as not to be bombarded with triggers from the access ports of users that turn on and off their computers).
But, as already mentioned, the exact same focus can be cranked with file systems and network interfaces of the computer (another example here ), as well as with many other things stored in SNMP. True, there are limitations. For example, unfortunately, the LLD will not work if the SNMP table contains several indices. It is possible to circumvent this restriction with the help of macros, however, this is already, as they say, from the category of “crutches”.
Like this. And no more fussing with similar data elements, triggers, graphs. Just set up LLD and enjoy the fruits of automation. Or configure LLD + network discovery and generally go on vacation :)
Source: https://habr.com/ru/post/193460/
All Articles