Long-Term Monitoring with SNMP
Pages: 1, 2
By default, mrtg measures network traffic. You can use it to measure any information given via SNMP MIBs, however.
First, you have to identify the MIBs available on your system. In an earlier article we discussed snmpwalk. Using it on the local system like such:
snmpwalk localhost private .1should spill the entire MIB tree.
If you're using the ucd-snmp described in previous articles, you're probably more interested in the ucd-snmp MIBs. You can pull those from the system by doing:
snmpwalk localhost private .1.3.6.1.4.1.2021The string at the end is the branch of the MIB tree that is reserved for ucd-snmp values. This generates a lot of output; you'll probably want to dump the results in a file.
Once you have a full list of MIBs, pick the values you want to monitor. The ucd-snmp MIBs list includes:
enterprises.ucdavis.memory.memIndex.0 = 0
enterprises.ucdavis.memory.memErrorName.0 = swap
enterprises.ucdavis.memory.memTotalSwap.0 = 204672
enterprises.ucdavis.memory.memAvailSwap.0 = 204648
enterprises.ucdavis.memory.memTotalReal.0 = 137096
enterprises.ucdavis.memory.memAvailReal.0 = 19180
enterprises.ucdavis.memory.memTotalFree.0 = 27032
enterprises.ucdavis.memory.memMinimumSwap.0 = 16000Long-term monitoring of a system's memory and swap is definitely useful.
You'll want to confirm that the MIBs mean what you think they mean, and convert them to numerical form. You can do both with the snmptranslate command.
Using snmpwalk only gives you the last section of the MIB. You have to know that the "enterprises" tree is always prefaced with .1.3.6.1.4. (This is common knowledge in the SNMP world.) You give this full MIB, and the -Td switch, to the snmptranslate command:
snmptranslate -Td .1.3.6.1.4.enterprises.ucdavis.memory.memAvailSwap.0.1.3.6.1.4.1.2021.4.4.0
memAvailSwap OBJECT-TYPE
-- FROM UCD-SNMP-MIB
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Available Swap Space on the host."
::= { iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) ucdavis(2021) memory(4) memAvailSwap(4) 0 }
This gives you a heap of useful information about the MIB, including its numerical equivalent and its definition. Take note of the numerical MIB; we'll need it soon.
The mrtg program charts MIBs in pairs, so you'll want to pick values to monitor accordingly. Sensible choices are things like "available swap and total swap," or "system memory and user memory." (Measuring available swap versus the percentage of disk available would give you difficult-to-understand charts.) We'll use user CPU time versus system CPU time as an example.
Digging through the snmpwalk output, and translating the system and user CPU times (enterprises.ucdavis.systemStats.ssCpuUser.0 and enterprises.ucdavis.systemStats.ssCpuSystem.0, respectively), we find that they translate to .1.3.6.1.4.1.2021.11.9.0 and .1.3.6.1.4.1.2021.11.10.0.
To make mrtg monitor these MIBs instead, you add them to the "Target" entry like so:
Target[localhost.cpu]:.1.3.6.1.4.1.2021.11.9.0&.1.3.6.1.4.1.2021.11.10.0:private@localhost
Be sure to pick a separate label for the target, and for all configuration statements for that target. If you don't, mrtg will either complain or overwrite the log files from other targets.
Test your configuration file by running mrtg on the command line a few times:
mrtg localhost.cfgThe first two times, mrtg will warn that it can't find log files, and then it should run silently. If you get an error that mrtg cannot reach a target, the Target entry is misconfigured. Either the community name, host name, or numerical MIB is wrong.
When mrtg runs silently, add it to cron to run every five minutes. If you followed the example above, when you look at http://localhost/mrtg/localhost.cpu.html, you'll see a pretty graph of your CPU usage over the last year.
You can use mrtg to monitor any system that uses SNMP. You can even install SNMP on your NT systems; this makes them easy to monitor, at a fraction of the cost of commercial systems. The only difference between mrtg and a commercial system is that you have to know what you're doing to use mrtg.
The first two articles in this series sparked dozens of e-mails from people wanting to use SNMP to monitor other platforms, such as Novell and NT. I highly recommend SNMP for the Public Community for SNMP on other 86 platforms. Be warned: To call NT's implementation of SNMP "skeletal" would leave you without an adequate description of its error messages.
SNMP is a rich and complex topic. We're finished with it for now, but in the next article we'll look at further customizing mrtg for your installation.
Read more Big Scary Daemons columns.
Discuss this article in the Operating Systems Forum.
Return to the BSD DevCenter.
