Ronald Nutter MCSE/MCNE
While searching for a good network tool that would allow me to see a heartbeat of what was occurring on my network, I came across a tool called MRTG, short for Multi Router Traffic Grapher. Normally, this utility is associated with Linux servers, but now you can use it with Windows 2000 servers as well. This article will walk you through the setup and basic implementation of MRTG on Windows 2000 to monitor an SNMP-aware device.
MRTG is a Perl-based package that will give you near real time feedback on the traffic load of SNMP-based devices or on activity such as free disk space, memory usage, etc. from Windows servers. As a part of collecting the information, MRTG generates HTML pages that can be used with Web servers. Except for your purchase of Windows 2000 Server, all the rest of the components required to get MRTG up and running are available for download at no cost.
Before you start
Starting out, make sure you have Windows 2000 Server installed and have applied all of the latest service packs, hot fixes, and security patches. You also need to make sure you've installed IIS 5.0 along with all of its security patches.
In order to make MRTG information easier to access, you'll need to create a Web page. Assuming that you will also be using FrontPage to create the Web pages, you will want to install FrontPage Server Extensions so that you can use FrontPage to author the Web pages that will collect the pages created by MRTG. This step doesn't occur automatically when installing IIS as you might expect. You can download the latest FrontPage Server Extensions from Microsoft's Web site.
You must also have the Perl language installed on your server. For the purposes of this article, I went with ActivePerl from Sophos. Installing it is beyond the scope of this article, but, as a general recommendation, I would suggest you download the MSI installation version because this version will give you an uninstall option that isn't available with the AS Package version.
The next step will be to download and install the MRTG package itself. You can get it from the MRTG Web site. Click on the Download MRTG link. You will see a list of files that you can download. You will want to look for the highest version number that has only a .zip for a file extension.
When I downloaded MRTG, the latest link available for Windows was mrtg-2.9.29.zip. While you can go with other versions that have extensions such as .tar.gz, you may need to go through a few additional steps to unpack the files from this type of archive.
When unzipping the file, I would recommend placing the unpacked files in a directory that shares the same name as the file that you downloaded. In my case, I created a directory named Mrtg-2.9.29 to hold the files. You should see a series of directories such as bin, contrib, and doc under the mrtg directory you created. Change to the bin directory, type Perl mrtg, and press [Enter]. You should get a message on the screen about a missing configuration file. This indicates that Perl and mrtg have been installed successfully.
Monitoring an SNMP device
The easiest device to monitor with MRTG is one that supports SNMP. For an example, in this article, I'll configure MRTG to monitor a Cisco Catalyst 6509 switch running in Native mode. The first step is to configure the device to respond to SNMP inquiries. We'll assume the Catalyst is already properly configured to respond to these inquiries.
The next step is to create the configuration file that MRTG will use to monitor the SNMP device you just enabled. You can manually create one using a Perl script called cfgmaker. MRTG itself can help you with that process.
Open a command window on your Windows 2000 server and change to the mrtg-2.9.29/bin directory. You will need to use a command line that looks like: Perl cfgmaker firstname.lastname@example.org –global "WorkDir: c:\inetpub\wwwroot\mrtg" –output mrtg.cfg
You will need to change a few things before using this command. The first thing you need to change is email@example.com. Replace this with the actual SNMP community name that you are using followed by @ and the ip address of the device that you want to monitor.
Depending on the number of ports that can be monitored on the device you are watching, you may find that quite a few files are created. On the network I use MRTG on, I found early on that I needed to create a separate directory for each building/major device that I was watching.
On the first device I set up, I had MRTG put files in C:\inetpub\wwwroot\mrtg. For each additional device, I had it place the files in a separate directory. I typically have used the building or device name as the name of the directory. The last thing is the name of the configuration file. Follow the same recommendations in terms of the naming of the configuration file that you do for the name of the directory.
Depending on the type of device you are running cfgmaker against, the process of creating the configuration for this process can take anywhere from a minute to 15 minutes or more. Once the file has been created, you will be returned to the command prompt. Before proceeding, take a moment and look at the .cfg file that cfgmaker has just created for you.
Depending on how you're using the device you're going to monitor, you may see one or more ports that are listed in the file but have # in front of them commenting them out from being executed. If you begin to use those ports, remember to go back into this file and uncomment them so you can see information abut the port in question.
Test the configuration file that you just created by typing Perl mrtg mrtg.cfg, replacing mrtg.cfg with the configuration file name including .cfg, and pressing [Enter]. If there isn't a problem, you should be returned back to the command prompt. You need to see it run once without errors before enabling the file to run continually.
Check the working directory specified in the .cfg file to make sure that you now have a collection of files in the working directory. You should have a series of files that end in .html, .log, .old, and .png. If you have one file that is named 10.1.7.1.76.html, there should also be a corresponding file with the extension .log, .old, and .png.
Once you're sure that you're getting the proper output, you can schedule MRTG. To get good information, you must have MRTG running the cfg file on a periodic basis. One way of doing this is to edit the .cfg file and place the following command in it: RunAsDaemon: Yes. (Make sure that you don't have a period after Yes.)
After you make this change, reexecute the Perl mrtg mrtg.cfg command. The script will now stay active and automatically rerun at 5-minute intervals. This means that you will have to leave a command window open so that the Perl process can continue to run. I like this approach, because I can quickly tell that things are running and see any errors as they come up. You can also run the Perl process as a service and not have the window open for the process to work.
Checking the output
Now would be a good time to look at the HTML files that MRTG has created for the device you are monitoring. Depending on the information that MRTG received when cfgmaker created the .cfg file, you may have some pages that are titled with some semi-cryptic header information that looks something like – 1—Cisco6509. You can change this by going into the .cfg file you created and making changes to the Title and PageTop configuration settings for each interface that you want to change. Once you have made the changes to the .cfg file, restart Perl and mrtg on this configuration file to continue collecting data.
This is one reason that I like to run a separate configuration file for each device that I monitor, so that I can shut down the monitoring for one device to make changes without having to shut down the entire MRTG system.
As you look at the HTML files created by MRTG, don't be immediately alarmed by what appears to be a lack of data in the pages. It will take several passes of MRTG, depending on the activity of the monitored device, to accumulate enough data to be able to show something on the graphs on the page.
Creating a summary snapshot with MRTG
As you increase the number of ports on a device that you are monitoring, you may find yourself doing a lot of clicking to see the activity on those ports to get an idea of how busy the device as a whole is. One of the goodies that comes with MRTG is something called Indexmaker. Unlike MRTG, Indexmaker is something that you will run on a one-time basis to set up the Web page. It actually builds a series of links to the other Web pages for this device that MRTG is already monitoring.
You start the process by opening a command window on the system running MRTG and then going to the mrtg-2.9.2\bin directory. Execute Perl indexmaker mrtg.cfg -output=c:\inetpub\wwwroot\mrtg\index.html. Replace mrtg.cfg with the name of the cfg file you want to use to build the summary page. Make sure that you have a double dash in front of the output keyword. Follow the equal sign by the drive letter, path, and name of the HTML file that you want the summary file to use when created.
The nice thing with Indexmaker is that you don't have to keep running the Perl script to update the HTML page that you have created. It builds an HTML file that links back to the files that mrtg.cfg (or whatever file you are referencing) has created. By default, it will link to the daily graph on each of the HTML pages specified in the .cfg file used by Indexmaker. Don't try to use these all at once; become familiar with how things work with just the minimum to get things running and then build from there. On the MRTG Web site, you will find more documentation on how to use some of the additional bells and whistles that Indexmaker has.
Monitoring a non-SNMP device
Let's face it, not every device supports SNMP. You will quickly find a whole host of links on the MRTG Web site that will lead you to other sites that show you how to monitor a variety of non-SNMP-aware devices. There is even a device available that will allow you to monitor the temperature inside your computer room or inside a particular server cabinet to make sure things don't get too hot.