You can combine
mrtg and a BSD system into a straightforward network status monitoring system. In an earlier column we looked at how to use
mrtg to set up basic monitoring; now we'll look at how to configure some of
mrtg's dustier corners.
If you're new to
mrtg, please look at the earlier article in this series.
Once you have a working
mrtg setup, you'll want to be careful testing new configurations. I generally test a new
mrtg configuration in a separate WorkDir, so that misconfigurations won't damage existing log files or production status pages.
mrtg.cfg file contains a wide variety of options that allow you to customize almost every aspect of
mrtg's appearance and function. Here you'll find some of the most useful
mrtg configuration options, and how they can be used in production environments.
mrtg log format condenses older entries. This tends to decrease
values over time. The
WithPeak option forces
mrtg to keep and graph the maximum values over time. Your graphs will be more complex, but the information will be more useful. This option can be set for the weekly, monthly, and yearly graphs, or any combination of these.
This is the maximum value that a MIB can reach;
mrtg uses this to decide if it got a sensible answer from the device. (The label is misleading if the MIB doesn't measure in bytes.)
Both MIBs being measured use the same
MaxBytes; be sure you're measuring sensible pairs! If you're doing something particularly weird, and need different
MaxBytes variables, you can use
This text will be put along the side of the graph. Put whatever you're measuring here, i.e., "% CPU Time."
LegendI[label] & LegendO[label]: text
Two MIBs are always measured by
mrtg. The first MIB is the traditional "In"
value, and the second the "Out." You can put short descriptions of
what you're measuring here. They'll appear beneath the graph.
Legend1[label] & Legend2[label]: text
Legend1 is the label for the first MIB you measure;
Legend2 is for the second. They'll appear at the bottom of your chart, in the key.
Legend3[label] & Legend4[label]: text
If you're recording maximums (with the
WithPeak option), these are the labels used for them. If you're not recording maximums, these labels have no effect.
mrtg setups can generate a lot of files. The directory label allows you to put the files for a particular target in a subdirectory of the WorkDir.
Options allow you to handle special cases. Some good examples are:
growright: By default,
mrtg draws graphs from right to left. If you want to go the other way, use this option.
bits: This changes the graphs from measuring bytes to bits. Bits are
not only more impressive, they may be more accurate depending on what
gauge: SNMP generally retains information in counter form, and
mrtg subtracts the previous reading from the current reading to get the
change in the last five minutes. The gauge option is for SNMP MIBs
that don't change, such as disk capacity.
unknaszero: When a target is not reachable for any reason (including
power failure or network problems), the system will assume the last
known value for the charts. Whether or not this is more accurate is a
matter of some controversy. This option causes
mrtg to assume a value
of zero when it cannot reach a target.
All this configuration can overwhelm you at first. Here's a sample
mrtg.cfg file for monitoring a FreeBSD system running ucd-snmp. Some parts will also work on other BSD systems, and work is underway to make it work completely on NetBSD. You can simply correct a few values to accurately represent your system's configuration. From this example, you can quickly generate your own
mrtg configuration for other MIBs.
The last bit of configuration we'll need to do is to create a single HTML index page for our
mrtg setup. The
mrtg program includes an
indexmaker tool that automagically does this for us. Just run
indexmaker mrtg.cfg > index.html
You'll probably want to edit this, but it's a nice starting place.
mrtg can be combined to form a powerful, flexible, and inexpensive network monitoring system. I strongly recommend this combination to all my clients. If you're new to these tools, you should use a version control system such as RCS to maintain your configuration files and allow you to recover from mistakes easily.
If you've never used RCS, be sure to check out the next Big Scary Daemons.
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.