Receive monitoring data via SNMP

SNMP (Simple Network Management Protocol) is a popular protocol family, supported by majority of network devices, as well as available for every more or less popular operating system.

One of most useful features of modern SNMP servers implementations is user-defined extensions. Simply put, one can instruct SNMP server to hold data returned by any user-defined action (such as output printed by a script or program). That can be used to use SNMP as container protocol, to deliver whatever data you need. Since version 3 of SNMP uses highly secure means of data transfer, it can be used to communicate with target host securely (avoiding possible data interception and/or forging). Let’s illustrate that.

User-defined SNMP data

The below assumes we are monitoring a Linux servers running modern implementation of Net-SNMP server.

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

(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. For “memAvail” it’s “8.109.101.109.65.118.97.105.108”.

User-defined SNMP traps

Custom SNMP Trap monitor can be generated manually. The advantage of this monitor: it’s active, it doesn’t depend on polling time and its “Event” alert will be executed the moment IPHost monitoring service receives the trap.

We have already documented the way to send such traps in corresponding KB article on how to send SNMP traps.

Since the trap monitor has only one type of alert type, it’s optimal to use it for severe alerts, when immediate reaction is expected.

If you would need more detailed setup steps to send a particular trap, feel free to contact us, or comment this post below.