sort of information you can read from your system.

Index Numbers

Now let's look at something that frequently confuses new SNMP users. Take the following snippet of snmpwalk output describing the disks on our system. Remember: snmpwalk reads the SNMP information available from a server; this is a small chunk of output from the complete listing of information available from snmpd.

...............................................................................................

enterprises.ucdavis.dskTable.dskEntry.dskIndex.1 = 1 enterprises.ucdavis.dskTable.dskEntry.dskIndex.2 = 2 enterprises.ucdavis.dskTable.dskEntry.dskIndex.3 = 3 enterprises.ucdavis.dskTable.dskEntry.dskPath.1 = /usr enterprises.ucdavis.dskTable.dskEntry.dskPath.2 = / enterprises.ucdavis.dskTable.dskEntry.dskPath.3 = /var enterprises.ucdavis.dskTable.dskEntry.dskDevice.1 = /dev/ad0s1f enterprises.ucdavis.dskTable.dskEntry.dskDevice.2 = /dev/ad0s1a enterprises.ucdavis.dskTable.dskEntry.dskDevice.3 = /dev/ad0s1e

...............................................................................................

All the partitions listed in snmpd.conf appear here. In the first three lines of the preceding example, we see that the dksIndex is a number from 1 to 3. Using snmptranslate, we learn that these are the reference numbers for the disk partitions we're monitoring; each partition has been assigned a unique index number.

In the next three rows, dskPath, we map the index 1 to /usr, index 2 to /, and index 3 to /var.

Then, in our next three entries, dskDevice, we see that there are three entries yet again. How do we use these disparate entries? By working backwards. For example, we see that dskDevice.1 is /dev/ad0s1f. We know that entry 1 is /usr, which tells us that /usr is on this physical device.

Because MIB trees are based on the information you want to pull, not the device that you want to access, a partition's information appears on nonconsecutive lines, making things slightly more difficult to read. But with a little patience, you'll be able to put it all together.

You'll see index numbers in anything SNMP reports that comes in multiple units. While disk partitions are the first one everyone stumbles across, you'll find that you'll get indexes for just about anything. Just look around for a key to these indexes; it'll be at the top of the section.

[3]Enjoyment is not a requirement, merely capability.

Long−Term Monitoring with MRTG

For long−term monitoring, we'll use a program that will query SNMP at specific intervals and record the answers it gathers. The most popular programs for this purpose are cricket and MRTG. Both are included in the FreeBSD ports collection and install cleanly on FreeBSD. We'll discuss MRTG (/usr/ports/net/mrtg) here.

MRTG, the Multi−Router Traffic Grapher, uses SNMP data to automatically generate reports on a Web page with nicely labeled graphs. MRTG can run as a daemon, but is traditionally a cron job run

441

every five minutes. You will need a Web server on the machine running MRTG.

You can use MRTG to give supervisors, managers, and co−workers convenient access to performance data without giving them server access. And, because MRTG keeps records over the course of a year, you can get a good idea of real−life trends. MRTG is also quite useful for justifying hardware and software expenditures, since you can point to exactly how much CPU time a machine is using, and how its performance has changed as you've added software.

Configuring MRTG

You can use the included cfgmaker(1) tool to generate a default MRTG configuration that measures network throughput on interfaces, like so:

...............................................................................................

# cfgmaker communityname@machine > mrtg.cfg

...............................................................................................

For example, if I wanted to run MRTG on my local machine, using the community name "GetLostLoser", I could run this command:

...............................................................................................

# cfgmaker GetLostLoser@localhost > mrtg.cfg

...............................................................................................

Cfgmaker makes SNMP queries of the specified device and generates a basic configuration file, which we dumped into the file mrtg.cfg in the preceding example. By default, MRTG monitors only network traffic.

Before you can use this configuration file, you need to add a "WorkDir" directive to the top of it to tell MRTG where to store its logs, graphics, working files, and HTML. I generally put the WorkDir somewhere under my Web server root directory, like this:

...............................................................................................

WorkDir: /usr/local/share/apache/htdocs/mrtg

...............................................................................................

You'll probably want to password−protect this directory, too, if the Web server is on the public Internet or otherwise exposed to the world at large. (See Chapter 15.)

Sample mrtg.cfg Entry

The generated mrtg.cfg has a lot of information, including some unnecessary HTML. If you look through the created file, you'll see that cfgmaker has generated a configuration for every single interface on the machine, which is proper because it measures network throughput by default. The loopback interface, and any down interfaces, are commented out; the remaining uncommented parts are a series of entries much like this:

...............................................................................................

vTarget w [localhost.3]: 3:GetLostLoser@localhost x MaxBytes[localhost.3]: 1250000

442

y Title[localhost.3]: petulance.blackhelicopters.org: xl0 z PageTop[localhost.3]: <H1>Traffic Analysis for xl0 </H1>

<TABLE>

<TR><TD>System:</TD><TD>petulance.blackhelicopters.org in Basement Server Room</TD></TR>

<TR><TD>Maintainer:</TD><TD>[e-mail]></TD></TR> <TR><TD>Interface:</TD><TD>xl0 (3)</TD></TR> <TR><TD>IP:</TD><TD>petulance.blackhelicopters.org (192.168.1.100)</TD></TR> <TR><TD>Max Speed:</TD>

<TD>1250.0 kBytes/s (ethernetCsmacd)</TD></TR> </TABLE>

...............................................................................................

Labels

The string inside the square brackets ([ ])(w) is an arbitrary label that indicates a unique subsystem being monitored. In this example, the label is localhost.3. This might be a network interface, the disk space on a partition, CPU usage, or anything. All files generated by MRTG for this monitored subsystem will have a name starting with this label.

To monitor any number of items, you must give each a unique label of any length. I usually create labels like "webserver1.EthernetTraffic" or "webserver9.AvailableSwap." Labels with names similar to the MIB you want to monitor are most useful, but they can become quite long, so strike a balance that you feel comfortable with.

Target

The Target keyword (v) tells MRTG which machine to query and which interface on that machine this configuration is for. (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. In this case, the target is 3:GetLostLoser¤localhost: an interface number, a SNMP community, and a hostname.

We spoke about indexes in MIBs earlier in "Index Numbers;" if you were to snmpwalk the MIB tree, you would find that this interface has the index number 3. You can dig through the snmpwalk output to find out which interface has this index number. Each interface has a unique IP address, however, and it's generally easier to use that to identify the interface. MRTG kindly includes the IP address a little later in the configuration.

MaxBytes

MaxBytes (x) is the maximum value allowed for this item. Since this is a network interface, MaxBytes is the maximum number of bytes this network card can handle (a 10BaseT card). MRTG has enough brains to figure out the MaxBytes values for most common network types.

You should never have to change this value if you're measuring throughput. You will have to change it to monitor other things, such as CPU or memory utilization.

Title and PageTop

Title (y) and PageTop (z) are arbitrary HTML. You can put almost any HTML in these spaces to display it on the generated MRTG Web page.

443

Edited Configuration File

Once I finish editing the basic MRTG config to my taste to monitor a network interface, it generally looks like this:

...............................................................................................

WorkDir: /usr/local/share/apache/htdocs/mrtg Target[webserver1.EthernetTraffic]: 3:GetLostLoser@localhost MaxBytes[webserver1.EthernetTraffic]: 1250000 Title[webserver1.EthernetTraffic]: Ethernet Interface PageTop[webserver1.EthernetTraffic]: <H1>Traffic Throughput for Ethernet Interface</H1>

<P>Call the Helpdesk if you have any questions

...............................................................................................

You'll notice that, first of all, the label has been changed to something meaningful. Also, the HTML under PageTop has been trimmed considerably, because 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 of lines of HTML after PageTop describing what the machine does or how to interpret the data.

You can list any number of machines or interfaces in one configuration file. Set up things appropriately for your system.

Testing MRTG

When you have a configuration you like, test it by running MRTG by hand a few times:

...............................................................................................

# mrtg mrtg.cfg

...............................................................................................

MRTG will warn you that it can't find log files the first two times, after which it should run silently. This alone is not a problem. However, if you get an error that MRTG cannot reach a target, the Target entry is misconfigured, and either the community name, hostname, or MIB is wrong. Check those, correct the problem, and try again. Once MRTG runs silently, add it to root's cron to run every five minutes. (You can also set up a specific user to run MRTG, but there's no real need for this.)

MRTG will send its output to the directory you specify in WorkDir in the configuration file. If you f o l l o w e d t h e p r e v i o u s e x a m p l e , w h e n y o u l o o k a t http://<hostname>/mrtg/webserver1.EthernetTraffic.html, you'll see a pretty graph of your network traffic since you started running MRTG. There are two different lines on the graph: one for inbound traffic, the other for outbound. MRTG measures things in pairs. You can see a sample MRTG graph in Figure 19.1.

444