Book HomeEssential SNMPSearch this book
PreviousNext

Chapter 13. MRTG

Contents:

Using MRTG
Viewing Graphs
Graphing Other Objects
Other Data-Gathering Applications
Pitfalls
Getting Help

The Multi Router Traffic Grapher (MRTG) is a freely available and fully configurable trend-analysis tool that's easy to configure and use. It's a surprisingly small, lightweight package because it doesn't implement a heavyweight user interface. Instead, it generates graphs in the form of GIF or PNG images; these graphs are embedded in standard HTML pages. Therefore, you can view MRTG's output using any graphical web browser and even make its reports visible across your network by using a web server.

Although MRTG is best at displaying usage graphs for router interfaces, it can be configured to graph things like memory usage, load average, and disk usage on server equipment. MRTG is particularly useful for determining when something "peaks out" for an extended period of time, which indicates that you have a capacity problem and need to upgrade. For example, you might find that your T1 interface is maxed out during your peak business hours and you need to upgrade to a bigger circuit, or you might find that you need to add more memory to a server. Likewise, MRTG may let you know that your network connections are operating at a fraction of the available bandwidth and that you can therefore eliminate a few T1 circuits and reduce your telecommunications costs.

Many sites that use MRTG use its default graphing capabilities for capacity planning and provisioning. MRTG doesn't provide the fine-grained statistical tools you need to calculate baseline information or project when your network will need to be upgraded. However, it can be a very useful tool for businesses that don't have the resources necessary to purchase a full-fledged trend-analysis package. Baselines and projections are invaluable, but MRTG's graphs can give you similar behavior at a glance; your eyes are very good at spotting typical behavior and trends, even if they can't give you the statistical analysis that your management might like.

MRTG has many options that allow you to customize how it operates. It is beyond the scope of this chapter to discuss every option; instead, we will discuss how to install MRTG and use its default graphing capabilities. We'll also outline how you can configure MRTG to gather system information from a server.

It's important to understand that MRTG is not an NMS solution. Although its graphing capabilities make it look superficially like an NMS, it's really a simple polling engine that's very clever about the output it generates. It performs the same get functions that an NMS would, but its job isn't problem detection and resolution. It doesn't have a facility for generating alarms or processing traps, nor does it have the ability to set objects. It's simply designed to provide a graphical view of how your network is performing. If you're interested in an open source NMS package, you should investigate Bluebird (http://www.opennms.org).

13.1. Using MRTG

Before using MRTG, you have to download and install the software. The primary MRTG web site is http://www.mrtg.org. The download link takes you to a directory maintained by MRTG's inventor and primary developer, Tobias Oetiker (http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/pub/ ). This directory contains some older MRTG releases, as well as the current one. We downloaded the file mrtg-2.9.10.tar.gz (the Unix version) from the list. We will focus on that version in this chapter.

MRTG requires four third-party packages in order to run: Perl Version 5.004_5 (at least), and the gd, libpng, and zlib libraries. MRTG comes with a Perl-based implementation of SNMP, so you don't have to worry about getting and installing any SNMP libraries. You can determine what version of Perl you have (and whether it's installed) by typing the command perl -v. This may or may not spit out a bunch of information. If it does, the first line will be the version of Perl you have installed. If you get some sort of "command not found" error, Perl may not be installed. In any event, go to http://www.perl.com to get the latest version of Perl.

The gd library is used to generate the GIF images that MRTG displays. You can download it from http://www.boutell.com/gd/. The other two packages, libpng and zlib, are also used for various aspects of graphic image creation. They are available from http://www.libpng.org/pub/png/.

Once you have ensured that Perl, gd, libpng, and zlib are installed on your machine, download and unpack the Unix version of MRTG with the following commands: 

[root][linuxserver] > cd /usr/local
[root][linuxserver] > tar -zxvf mrtg-2.9.10.tar.gz
Once it's unpacked, cd into the directory it created (which should be mrtg-2.9.10) and read the installation hints from the README file. To build MRTG, you execute three commands: 

[root][linuxserver] ~/mrtg-2.9.10> ./configure
[root][linuxserver] ~/mrtg-2.9.10> make 
[root][linuxserver] ~/mrtg-2.9.10> make install
All three of these commands produce a lot of output, which we have omitted. The configure command inspects your system for tools it needs to build MRTG. It will tell you which items are missing and where to go to get them. Running make builds MRTG, but don't bother running this if the configure command failed; MRTG will not build unless everything has been installed and configured properly. Finally, make install installs MRTG and its associated files in the appropriate places. Again, don't bother running make install if the previous make command terminated with errors. The default location for the MRTG executables is /usr/local/mrtg-2/bin. You may want to add this directory to your search path.

Once you've built MRTG, you need to decide where to put the graphs it generates. Since MRTG's graphs are designed to be viewed by a web browser, they're often stored in a directory that's visible to a web server. However, it really doesn't matter where they go. What's more important is who you want to view the graphs. You probably don't want the world to see your network statistics. On a small network, you can place the graphs in a directory that is out of view of the web server and then use a web browser to view the HTML reports in the local filesystem. In a larger network, other people (e.g., other network staff or management) may need to access the reports; to allow access without publishing your network statistics to the rest of the world, you may want to set up some kind of a secure web server. At any rate, the next set of commands you'll want to execute is something like this: 

[root][linuxserver] ~/mrtg-2.9.10> mkdir /mrtg/images
[root][linuxserver] ~/mrtg-2.9.10> cp ./images/mrtg*.gif /mrtg/images/
The first command creates a directory for storing the graphs MRTG creates. The second command copies some MRTG images into the newly created directory for later use in HTML files. For the remainder of this chapter, we will assume that graphs are stored in /mrtg/images.

You're now ready to set up your first device to poll, which is called a target in MRTG. MRTG uses a configuration file to tell it what devices to poll, what options to apply to the creation of the graphs it will generate, etc. The syntax of the configuration file is complex, but MRTG provides a tool called cfgmaker to help you build it. You'll probably need to edit the file by hand, but it's much easier to start with a working template. Here's how to execute cfgmaker: 

[root][linuxserver] ~/mrtg-2.9.10> setenv PATH /usr/local/mrtg-2/bin:$PATH
[root][linuxserver] ~/mrtg-2.9.10> cfgmaker --global 'WorkDir: /mrtg/images' \
--output /mrtg/run/mrtg.cfg public@router
The first argument to cfgmaker sets the WorkDir variable in the configuration file. This tells MRTG where to store any data it gathers from the devices it's going to poll. The second argument specifies where we want cfgmaker 's output sent; in this case it's /mrtg/run/mrtg.cfg. The last argument specifies the device we want to poll and the community string to use when polling that device; its format is community_string@device.

The output from cfgmaker is a mix of commands and HTML. It performs get-next commands on the device you specified on the command line, in order to get an idea of how many interfaces your device has, which ones are up, which are down, etc. It walks the iso.org.dod.internet.mgmt.mib-2.interfaces (1.3.6.1.2.1.2) tree to discover the total number of interfaces in this table. It then creates logical entries that represent a list of devices to poll, except the list of devices is actually one device with each interface number specified as a target. For example, Ethernet0 is in the fourth row of the interfaces table on our Cisco router, so cfgmaker created a Target entry called cisco.4. If this interface occupied the second row in the interfaces table, the Target entry would be called cisco.2.

Here's a shortened version of our mrtg.cfg file: 

WorkDir: /mrtg/images/

Target[cisco.4]: 4:public@cisco
MaxBytes[cisco.4]: 1250000
Title[cisco.4]: cisco (cisco): Ethernet0
PageTop[cisco.4]: <H1>Traffic Analysis for Ethernet0
 </H1>
 <TABLE>
   <TR><TD>System:</TD><TD>cisco in Atlanta, Ga</TD></TR>
   <TR><TD>Maintainer:</TD><TD></TD></TR>
   <TR><TD>Interface:</TD><TD>Ethernet0 (4)</TD></TR>
   <TR><TD>IP:</TD><TD>cisco (  )</TD></TR>
   <TR><TD>Max Speed:</TD>
       <TD>1250.0 kBytes/s (ethernetCsmacd)</TD></TR>
  </TABLE>
It's worth learning a bit about the format of the configuration file. Comment lines begin with #; in a real configuration file, you'll see many of them. Most of the lines in the file are either commands or snippets of HTML that will be used in MRTG's output files. MRTG commands take the form of command[key]: options. For example, the command for the third line is Target, the key is cisco.4, and the options are 4:public@cisco. The key is an identifying string that groups entries in the configuration file and provides a base filename for MRTG to use when generating graphs and HTML files. At a complex site, MRTG might be used to monitor dozens of pieces of equipment, with hundreds of interfaces; the key keeps the configuration file in some semblance of order. The options provide the actual parameters to the command.

This should help you understand the configuration file. The first line specifies the working directory in which MRTG will place its graphs and HTML files. This is a global command, so no key is needed. The working directory is typically somewhere under a web server tree, so that MRTG's reports can be visible from a web browser. We've set ours to /mrtg/images/. The third line (Target) tells MRTG which device it should poll. The format for this option is interface:community_string@device, or in our case 4:public@cisco. The device is specified by its hostname or IP address; we already know about community strings. Since MRTG is only a data-collection tool, the read-only community string will suffice. Interface specifies which interface on the device to poll, according to the device's ifTable. In this case, we're polling interface 4 in the ifTable.

The MaxBytes line sets up the maximum value for the parameters MRTG is going to read from this interface. By default, MRTG reads ifInOctets and ifOutOctets. It tries to pick a reasonable maximum value depending on the interface's type, which it should be able to read from the device itself. Since this is an Ethernet interface, MRTG sets MaxBytes to 1250000. The Title specifies the title for the HTML page generated for the graph. Finally, PageTop and the following lines tell MRTG what kind of information to place at the top of the HTML page containing the usage graphs. The command contains actual HTML code, which was generated by cfgmaker.

Altogether, this entry tells MRTG to poll for the default objects (ifInOctets and ifOutOctets) on entry 4 in the interface table for the device cisco. Therefore, MRTG will issue get commands for the OIDs .1.3.6.1.2.1.2.2.1.10.4 (iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifInOctets.4 ) and .1.3.6.1.2.1.2.2.1.16.4 (iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifOutOctets.4 ). By default, MRTG will generate the following graphs:

Once you've finished, try running MRTG by hand to see if there are any problems with the configuration script: 

[root][linuxserver] ~/mrtg-2.9.10> mrtg /mrtg/run/mrtg.cfg
If MRTG has no problems with your configuration file, it will run with no configuration-file errors. If it does have problems, it will give you a fairly verbose description of the problem. The first time you run MRTG, it will complain about not being able to find any log files. If you run MRTG three times you'll see messages similar to these: 

[root][linuxserver] ~/mrtg-2.9.10> mrtg /mrtg/run/mrtg.cfg
Rateup WARNING: /mrtg/run//rateup could not read the primary log file for cisco.4
Rateup WARNING: /mrtg/run//rateup The backup log file for cisco.4 was invalid as 
well
Rateup WARNING: /mrtg/run//rateup Can't remove cisco.4.old updating log file
Rateup WARNING: /mrtg/run//rateup Can't rename cisco.4.log to cisco.4.old 
updating log file
   
[root][linuxserver] ~/mrtg-2.9.10> mrtg /mrtg/run/mrtg.cfg
Rateup WARNING: /mrtg/run//rateup Can't remove cisco.4.old updating log file

[root][linuxserver] ~/mrtg-2.9.10> mrtg /mrtg/run/mrtg.cfg
[root][linuxserver] ~/mrtg-2.9.10>
As you can see, the first time we ran the program it spat out some errors. The second run produced only one error, and the last time it ran with no errors. These errors are normal when you run MRTG for the first time; don't worry about them.

The next step is to make sure MRTG runs every five minutes. There's no need for MRTG to be run by root; any user will do. Add a line like the following to the crontab entry for the appropriate user: 

*/5 * * * * /usr/local/mrtg-2/bin/mrtg /mrtg/run/mrtg.cfg
This runs MRTG every five minutes of every day. Note that the */5 notation is Linux-specific; on other Unix systems you'll have to specify the times explicitly (0,5,10,15,20,25,30,35,40,45,50,55). If your network is fairly large, you might run into problems if MRTG does not finish all its polling duties before the next polling cycle starts. If this is the case, setting a five-minute poll interval may not be a good idea. You may have to experiment to determine a good interval for your environment.

PreviousHomeNext
12.6. Port MonitorBook Index13.2. Viewing Graphs
Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.