Receive monitoring data via SNMP
SNMP (Simple Network Management Protocol) is a widely supported protocol family used by network devices, servers, and many operating systems.
One useful feature of some SNMP agents is support for user-defined extensions. In practice, this means the SNMP service can expose the output of your own script or program as an SNMP value, which makes SNMP a convenient transport for custom monitoring data. Modern agents and tools such as Net-SNMP support SNMP v1, v2c, and v3; for production use, SNMPv3 is the preferred choice when you need authentication and privacy.
User-defined SNMP data
The example below assumes we are monitoring a Linux server running a modern Net-SNMP agent. The extend directive documented by Net-SNMP is still a practical way to expose custom script output through SNMP.
Add to SNMP daemon default configuration file (such as /etc/snmp/snmpd.conf) line like the below:
extend memAvail /usr/local/bin/memavail.sh
and create (and make executable) script file /usr/local/bin/memavail.sh with the below content:
#!/bin/bash
free -m | head -2 | tail -1 | awk '{print $7;}'
(the above command will report in most modern Linux distributions the amount of RAM available for processes).
Re-start SNMP service (daemon) and run, locally or from a different system, command like this:
snmpwalk -v2c -On -c public snmphost .1.3.6.1.4.1.8072
For simplicity, this example uses SNMPv2c and the default public community only as a local test case; in production, it is better to use SNMPv3 or at least non-default read credentials.
(where “snmphost” is DNS name or IP address of the assumed SNMP server, and default read-only community “public” is in effect). If everything has been set up properly, the following lines (with probably different OID part after the strings displayed in bold) will appear:
.1.3.6.1.4.1.8072.1.3.2.2.1.2.8.109.101.109.65.118.97.105.108 = STRING: "/usr/local/bin/memavail.sh" .1.3.6.1.4.1.8072.1.3.2.2.1.3.8.109.101.109.65.118.97.105.108 = "" .1.3.6.1.4.1.8072.1.3.2.2.1.4.8.109.101.109.65.118.97.105.108 = "" .1.3.6.1.4.1.8072.1.3.2.2.1.5.8.109.101.109.65.118.97.105.108 = INTEGER: 5 .1.3.6.1.4.1.8072.1.3.2.2.1.6.8.109.101.109.65.118.97.105.108 = INTEGER: 1 .1.3.6.1.4.1.8072.1.3.2.2.1.7.8.109.101.109.65.118.97.105.108 = INTEGER: 1 .1.3.6.1.4.1.8072.1.3.2.2.1.20.8.109.101.109.65.118.97.105.108 = INTEGER: 4 .1.3.6.1.4.1.8072.1.3.2.2.1.21.8.109.101.109.65.118.97.105.108 = INTEGER: 1 .1.3.6.1.4.1.8072.1.3.2.3.1.1.8.109.101.109.65.118.97.105.108 = STRING: "7905" .1.3.6.1.4.1.8072.1.3.2.3.1.2.8.109.101.109.65.118.97.105.108 = STRING: "7905" .1.3.6.1.4.1.8072.1.3.2.3.1.3.8.109.101.109.65.118.97.105.108 = INTEGER: 1 .1.3.6.1.4.1.8072.1.3.2.3.1.4.8.109.101.109.65.118.97.105.108 = INTEGER: 0 .1.3.6.1.4.1.8072.1.3.2.4.1.2.8.109.101.109.65.118.97.105.108.1 = STRING: "7905"
Note that actual meaning is defined by an infix (in bold), namely:
2.1.2: nsExtendCommand (command run to send data to standard output) 2.1.3: nsExtendArgs (command-line arguments for the command) 2.1.4: nsExtendInput (input taken by the command) 2.1.5: nsExtendCacheTime (for how long does SNMP service keeps that data as actual output, in minutes) 2.1.6: nsExtendExecType (how exactly the command was invoked) 2.1.7: nsExtendRunType (when the command is actually run) 2.1.20: nsExtendStorage (how the output is stored; permanent: 4) 2.1.21: nsExtendStatus (1 if active) 3.1.1: nsExtendOutput1Line (first line of command output) 3.1.2: nsExtendOutputFull (full command output) 3.1.3: nsExtendOutNumLines (number of lines in output) 3.1.4: nsExtendResult (result code the command returned) 4.1.2: nsExtendOutLine (a single line of output)
The OID “tail” after the above is generated in the following manner: sequence of decimal values of every character in the extension identifier (“memAvail”) prepended by the number of characters in that string. In practice, you do not need to calculate such OIDs manually every time — snmpwalk output is often the quickest way to confirm the exact OID branch and returned value before creating the monitor in IPNetwork Monitor. For “memAvail” it’s “8.109.101.109.65.118.97.105.108”.
User-defined SNMP traps
An SNMP Generic Trap monitor can be created manually. Its main advantage is that it is event-driven: it does not depend on polling time, and its Event alert can be executed as soon as the IPNetwork Monitor service receives the trap.
We have already documented the way to send such traps in the corresponding KB article on how to send SNMP traps. When setting up a new trap workflow, it is best to first verify the actual trap receiver UDP port shown in “Settings > System”, because it may differ from 162 if that port is already occupied. Then create a test SNMP Generic Trap monitor that accepts any OID and any community, confirm that traps are arriving, and only after that narrow the filter to the values you actually need.
It is also helpful to attach an e-mail alert to that temporary test monitor, because the received trap data shown in the notification makes debugging much easier.
If you would need more detailed setup steps to send a particular trap, feel free to contact us.