We've seen how SNMP can be used to gather just about any information from a host. You can interpret this data through a wide array of programs. The most popular are
mrtg. Both are included in the FreeBSD ports collection, and install cleanly on any BSD. Here, we'll discuss
mrtg program uses SNMP data to automatically generate reports on a web page with cleanly labeled graphs. You can give supervisors, managers, and coworkers convenient access to performance data without giving them server access. It keeps records over a whole year, so you can get a good idea of real-life trends. It's also quite useful for justifying hardware and software expenditures; you can point out exactly much CPU time a machine is using, and how it's changed as you've added software.
You can run
mrtg as a daemon, but it is traditionally a cron job run every five minutes.
mrtg call requires a config file. You can use the included
cfgmaker tool to generate a default configuration for measuring network throughput on interfaces. The
cfgmaker tool is easy to use:
cfgmaker communityname@machine > mrtg.cfg
For example, if I wanted to run
mrtg on my local machine, I could run:
cfgmaker private@localhost > localhost.cfg
cfgmaker tool will make SNMP queries of the device and generate a configuration file. It includes a lot of information, including some unnecessary HTML. If you look through the created file, you'll see that
cfgmaker has thrown up a configuration for every single interface on the machine. The loopback interface, and any down interfaces, are commented out. The remaining, uncommented parts will look like this:
Title[localhost.3]: moneysink.exceptionet.com (No hostname defined for IP address): ep0
PageTop[localhost.3]: <H1>Traffic Analysis for ep0
<TR><TD>System:</TD><TD>turtledawn.blackhelicopters.org in Right here, right now.</TD></TR>
<TR><TD>IP:</TD><TD>No hostname defined for IP address (192.168.1.100)</TD></TR>
<TD>1250.0 kBytes/s (ethernetCsmacd)</TD></TR>
Before you can use this configuration, you need to add a
WorkDir directive to the config file.
mrtg where to store its logs, graphics, and HTML. I generally put the
WorkDir somewhere under my web server root, such as:
You'll probably want to password-protect this directory if the web server is on the public Internet or otherwise exposed to the world at large.
The "target" keyword tells
mrtg which machine to query, and which interface on that machine this configuration is for. The string inside the brackets (
) is an arbitrary label. All files generated by
mrtg will be be named with this label as a prefix. The actual target appears after the colon. If you change the community name or IP address of your system, you can edit it directly here.
MaxBytes is the maximum throughput allowed through the interface. In this case, we have a 10baseT card. The
mrtg program has enough brains to figure out the values for most common network types. You should never have to change this value if you're measuring throughput.
PageTop are arbitrary text. You can put almost any HTML in these spaces, and it will be displayed.
Once I finish editing the
mrtg config to my taste, it generally looks like this:
Target[localhost.3]: 3:private@localhost MaxBytes[localhost.3]: 1250000 Title[localhost.3]: Ethernet Interface PageTop[localhost.3]: <H1>Traffic Analysis for Ethernet Interface</H1> <P>Call the Helpdesk if you have any questions
I know perfectly well where the system is, after all, and who to talk to about it. If these pages are intended for management, I might add a couple lines of HTML after
PageTop describing what the machine does, or how to interpret the data.
You can list any number of machines and/or interfaces in one configuration file. Just be sure each target has a unique label.
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 .1
should 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 .184.108.40.206.4.1.2021
The 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 = 16000
Long-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
Using snmpwalk only gives you the last section of the MIB. You have to know that the "enterprises" tree is always prefaced with
.220.127.116.11.4. (This is common knowledge in the SNMP world.) You give this full MIB, and the
-Td switch, to the
snmptranslate -Td .18.104.22.168.4.enterprises.ucdavis.memory.memAvailSwap.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.
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.ssCpuSystem.0, respectively), we find that they translate to
mrtg monitor these MIBs instead, you add them to the "Target" entry like so:
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:
The 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.
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
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.
Michael W. Lucas
Read more Big Scary Daemons columns.
Discuss this article in the Operating Systems Forum.
Return to the BSD DevCenter.
Copyright © 2009 O'Reilly Media, Inc.