sysadmin HQ

The true power of Cacti comes from its ability to gather data from sources outside of what snmp will give you out of the box.  By creating custom data input methods, you can graph everything and anything your heart desires – be it page load times for a URL, or the number of messages in a sendmail queue.

For a long time I would write custom data input methods (generally bash scripts employing a lot of sed and awk), and would then struggle to find ways to get my data into Cacti. I’ve used a lot of cheap hacks in the past, even going so far as simply having my shell script write to a file on a shared NFS volume. Then my “data input method” would be a shell script that would do “tail -1″ on the file! (oh my, the hackness!) .

Then I realized there is a better way. Cacti is a powerful snmp monitoring tool, and the net snmp agent is designed to be easily extendable to custom scripts. Combine the two, and you no longer have to worry about how you’re going to get your data points from your monitored host to your cacti server.

Let’s say you’re interested in monitoring a memory statistic on a Linux host that you can’t get from the built in mibs. For example, “HugePages_Free. “

Writing a shell script to grab this value is pretty easy, and you could go about it any number of ways. Here’s my kiss-principle based method:

#!/bin/bash

memvar=$1

#/usr/local/bin/meminfo.sh

memresult=`cat /proc/meminfo |grep $memvar |awk ‘{print $2}’`

printf $memresult

In the above example, I’ve chosen to pass whatever meminfo I want to graph as a command line argument, that way if I decide later I want something else the script is already set up. Now that bash scripting for 1st graders is over, we can get on with the business of sending the return value of this script to cacti.

Open up your /etc/snmp/snmpd.conf file, and append something like this at the bottom.

extend meminfo /usr/local/bin/meminfo.sh HugePages_Free

“Extend” is the directive, “meminfo”is an arbitrary name that can use as a referent later, and the last part is just the path to my shell script, including the command line argument I set the script up to accept.

The extend directive allows you to either specify an OID, or just let the value get returned to the nsExtendOutput1Table.  As you can see in my example, I chose the default table. However you do it is up to you. For more details, do a man on snmpd.conf.

 
After you’ve restarted you snmp daemon, its time for a quick test. Try using snmpwalk from your cacti server and see what you get back (wrapped for readablity)

>snmpwalk -c rocommstring -v1 remoteservername ‘NET-SNMP-EXTEND-MIB::nsExtendOutput1Line.”meminfo”‘

Should produce:

#NET-SNMP-EXTEND-MIB::nsExtendOutput1Line.”meminfo” = STRING: 2154

Note1 – inside the quotes we specified the name that we had used in our snmpd.conf file for this extension.

What you’re hoping for here is that the string you get back though snmpwalk matches what the real script outputs back on “remoteserver”. In my case, the system had 2154 huge pages free at the time I did this query.

Note2 – the use of single and double quotes in the snmpwalk command are significant. The command won’t work without them. Not an issue when we get to the cacti phase, as you’ll see shortly.

So, we know our script has been brought under the umbrella of snmp and can be referenced accordingly. Now over to cacti.

For starters, create a new data template.

If you’re a regular cacti user, the various fields here are familiar so I won’t go into them. The first one your interested in is “Data Input Method”. You will choose “Get SNMP Data”

 

Depending on your cacti version, you might have to save the template at this point, and re-open it, in order to see the updated fields at the lower half of the screen. The next field we’re interested in is the OID field. We will input something very similar to what we used in the snmpwalk command; the difference is we need not worry about the single quotes.

… and there you have it. You can now proceed to creating your data sources, and associated graph templates just as you normally would for any other data source.

Footnote:

Most of the documentation I’ve seen on this topic all reference the snmp “exec” directive, instead of the “extend” directive. The exec directive works fine, but is deprecated in newer versions of snmp. If you happen to be using a system with an older version of snmp, you follow the same steps, but substitute “exec” for “extend” in your snmpd.conf file. These entries are not indexed by name, and are instead rooted under OID .1.3.6.1.4.1.2021.8.1. So, assuming you had a single exec value in your snmpd.conf, you would substitute .1.3.6.1.4.1.2021.8.1.101.1 for the oid string above.