MRTG

[patris1]

http://articles.techrepublic.com.com/5100-10878_11-6068756.html?tag=rbxccnbtr1

Graphing router usage with MRTG


Takeaway: Learn to use the Multi Router Traffic Grapher (MRTG) tool to capture important data from network routers and systems.
Capturing data from network routers and systems can be both interesting and enlightening. This data is sometimes not so easy to obtain, but using tools like MRTG (available here) can make it easier to both obtain and monitor. MRTG, which stands for Multi Router Traffic Grapher, can be used to graph more than just traffic data from your router; but here, we'll look at an initial setup to allow MRTG to read data from a Linksys BEFSR81 router.
The first step is to enable SNMP access in the Linksys router by going to the administrative Web interface and selecting Administration. Here you can enable SNMP and provide a few settings; the important one right now is just to turn SNMP support on.
If your distribution ships with MRTG, install the package. If not, download it and be sure you have the development libraries for GD, libpng, and zlib installed. You will also need a working perl installation.
Once MRTG is installed, create an initial configuration file:
# cfgmaker -global 'WorkDir: /var/www/html/mrtg' --output=/etc/mrtg.cfg \--global 'Options[_]: bits, growright' --output=/etc/mrtg.cfg \public@10.0.5.1 This really long command is all that's needed to tell MRTG to poll data from the router using SNMP. All the MRTG data will be viewable in the /var/www/html/mrtg directory. The public@10.0.5.1 in the above snippet is the Get Community setting in the Linksys router and the IP address of the router.
Once this finishes and the configuration file is created, it's time to run MRTG and collect some data. On the first two runs you'll get errors; these can safely be ignored as MRTG is complaining about the lack of history data. Subsequent runs should complete without error. To run MRTG enter:
# mrtg /etc/mrtg.cfg To create the Web page data, use the indexmaker tool like this:
# indexmaker -output=/var/www/html/mrtg/index.html -
title="Network MRTG" -sort=title When you browse the /mrtg/ directory on the server, this code will make the index.html file display the MRTG data; links on specific graphs will allow you to view further detailed data.
Finally, to update MRTG's data in a consistent fashion, use cron to execute MRTG every 5 minutes. This can be done with the following crontab entry:
*/5 * * * * /usr/bin/mrtg /etc/mrtg.cfg --logging /var/log/mrtg.log MRTG is extremely powerful, and this is just the tip of the iceberg. There are hundreds of things you can use MRTG to graph, but the first step is getting it up and running. If you use a Linksys router, or any other router that supports SNMP, you can start with graphing network and bandwidth usage

---

موضوعات مشابه:

• مشکل در کانفیگ MRTG
• MRTG ConfigMaker & Create MRTG configuration scripts
• مشکل mrtg
• مشکل MRTG
• MRTG

---

[patris1]

http://articles.techrepublic.com.com/5100-10878_11-1049419.html

Takeaway: Install, configure, and use MRTG on Linux to monitor network systems and devices by using this tutorial as your guide.

MRTG, or Multi Router Traffic Grapher, is a popular monitoring and statistics tool for use on Linux platforms. It was designed to monitor the traffic load on network links, but it's highly extensible and configurable. Not only can you watch interfaces on routers and switches, but you can also analyze Linux system variables. Although this is usually done with the Simple Network Management Protocol (SNMP), MRTG also supports the use of local scripts to feed it data. The data is then converted into HTML with graphs in PNG format for a visual representation of your network.

Overview of SNMP
Before we delve too deeply into the installation and configuration of MRTG, it is important to understand how MRTG and SNMP work together. By default, MRTG will take an SNMP community string and a device hostname or IP address and discover what it needs to know. This is done by polling Management Information Base (MIB) objects predefined for all SNMP-ready devices. A MIB is basically a database of variables that corresponds to a system value. Basic examples include information such as system name, interface type, and uptime.

Most vendors will have MIBs for their line of products, and these will conform to SNMP standards. On the device, SNMP then needs to be enabled and a community string set. Such configurations will vary from vendor to vendor and sometimes from device to device. On Cisco products, for instance, the configuration command snmp-server is used as follows:
snmp-server community c1sc0 RO

This informs the Cisco IOS to provide read-only access to a querying SNMP tool that provides the community string c1sc0. It is best that you treat SNMP strings like passwords and configure them appropriately. SNMP is probably already configured and running if you currently use other network and system monitoring tools, such as HP OpenView, Cisco Works, or OpenNMS.

Linux will also need to be configured to provide real-time data to MRTG. This can be done with SNMP or through the use of local scripts. To listen for incoming SNMP requests, you will need to install and configure snmpd. Configuration is done through the snmpd.conf file and requires you to set your community string. For a standard UCD SNMP implementation, the line in snmpd.conf will look something like this:
com2sec readonly default liNuX42

Notice that once again, we are giving only read-only access to SNMP agents. Read-write access is also configurable, but if you don't need it, don’t configure it. With read-only, you will be able to view only statistics and configuration options. Although this is something that should be monitored closely for security reasons, it is not nearly as dangerous as allowing remote commands to be executed via SNMP.

Installing and configuring MRTG
MRTG, like more and more packages these days, should be available through your favorite automated installer. So whether it is APT or up2date, that is usually the quickest way to get it onto your system. Alternatively, source and RPM distributions are available from the maintainer’s site at MRTG.org. MRTG has a number of dependencies as well, the most important being Perl, gd, libpng, and zlib. Keep this in mind during installation if you encounter problems. Source code installation follows the standard scheme with:
tar xpfz mrtg-2.9.18.tar.gz
./configure
make
make install

Installing with RPM is also easy. The package name may vary, but you simply use the command:
rpm –ivh mrtg-2.9.18.rpm

Once MRTG is installed on your system, you may need to configure a Web directory where it will place its HTML and PNGs for viewing. Use mkdir to create a directory called mrtg under your main HTTP path and modify your permissions. For example:
mkdir /var/www/mrtg
chmod 755 /var/www/mrtg

The next step is to create a configuration for MRTG to use. The quickest way to do this is by running cfgmaker and passing it the SNMP community string and device and outputting it to a text file, like this:
cfgmaker c1sc0@192.168.66.72 > /etc/mrtg.cfg

Then, edit the new mrtg.cfg file and add a line listing the path to your working directory (where your MRTG-related files will be stored), like this:
WorkDir: /var/www/mrtg

Note that the device can be represented as either an IP address or a hostname. Also, cfgmaker can support a variety of options and settings at the command line, depending on the version. The best way to get started, though, is to use the default options. You can always make changes directly to the configuration file later.

The basic configuration file will look something like this:
Target[192.168.66.72.1]: 1:c1sc0@192.168.66.72
MaxBytes[192.168.66.72.1]: 1250000
Title[192.168.66.72.1]: RTR2: Ethernet0/0
PageTop[192.168.66.72.1]: <h1>Traffic Analysis for Ethernet0/0</h1>

These are just a few of the many options that can be placed into the MRTG configuration file. The first value here is Target. Inside the brackets is a unique name that will allow separate options for multiple devices and interfaces. Then, we have what will actually be providing the data, in this case, SNMP.

Next, we have the MaxBytes option. This is how the upper end is configured, and it's what percentage values are based on. It will vary between mediums and targets, depending on what you are polling. The next two options are for the HTML and act as descriptors.

Local scripts provide another way to get information to MRTG. These can range from simple to complex shell and Perl scripts. We’ll look at how to do a simple shell script that will provide MRTG with data on packets inbound to an iptables firewall.

First, we will create the script, /usr/local/mrtg/iptables-in:
#!/bin/bash
IPTABLES="/sbin/iptables"
UPTIME="/usr/bin/uptime"
$IPTABLES -nvxL | grep INPUT | awk '{ print $5 }'
$UPTIME | awk '{ print $3, $4, $5 }'

This script will pull the number of packets it has accepted from the INPUT rule. It uses grep to search for the line containing INPUT and prints only the fifth value, which in this case is the number of packets processed. The uptime command is used so that MRTG will know how much time has passed between each value and can chart it over a period of time.

The mrtg.cfg will then look something like this:
WorkDir: /var/www/mrtg
Target[in_packets]: `/usr/local/mrtg/iptables-in`
MaxBytes[in_packets]: 1500
Title[in_packets]: Inbound packets
PageTop[in_packets]: <h1>Inbound Packet Stats</h1>

This is similar to the configuration used for SNMP above; however, we are pointing the target to an external script called iptables-in. We are also setting a fairly arbitrary MaxBytes setting since we are dealing with packets as opposed to bits or bytes. This will vary from system to system and a few different values may need to be tried. Although this is a rather simple example, it should give you an idea of what is possible with MRTG. Any data you can gather via the command line can be imported into MRTG and graphed in real time.

Running MRTG
Once MRTG has been installed successfully, you will need to configure it to run on your system. MRTG can be run manually as follows:
/usr/bin/mrtg /etc/mrtg.cfg

MRTG updates its log files every time it is run. The first two times, all the files will not have been created and you may see errors. These can be ignored, but anything you see on the third time around will probably warrant closer investigation.

It is a good idea to configure cron to run the program, as MRTG will need to execute often to poll devices and gather data. The standard interval is five minutes, but you can change it to fit your particular needs. Place an entry in /etc/crontab giving the interval, user to run as, path to mrtg, and the path to mrtg.cfg like this:
*/5 * * * * root /usr/bin/mrtg /etc/mrtg.cfg

Once MRTG is configured and running, all you will need to do is access the pages through a Web browser. You may want to tweak the HTML manually to do such things as index multiple devices and enable auto-refresh. Figure A shows a sample graph to give you an idea of what the finished product will output.

Figure A

Summary
MRTG is a powerful and extensible tool that will allow you to graph network links and system information over a configurable period of time. Utilizing SNMP, local scripts, or a combination of the two, MRTG allows you to easily monitor your devices. Such things as trends, traffic spikes, and slow periods are easy to detect with a visual representation. MRTG does this in excellent form, outputting data in HTML and PNG formats viewable through a Web browser. MRTG doesn't have all the bells and whistles of commercial monitoring software, but it does the job well and is definitely worth considering as part of your network monitoring activities

[patris1]

http://articles.techrepublic.com.com/5100-10878_11-1053305.html?tag=rbxccnbtr1

Takeaway: Finding a network-monitoring tool that's not expensive and complex can seem like a never-ending task. Fortunately, Scott Lowe did a good deal of footwork and found one in MRTG. Here, Scott explains its installation and usage.

Every network and systems administrator needs tools that can accurately display usage statistics and possible problem areas in his or her infrastructure. However, many of these tools are very expensive and complex and do more than is required to get the job done.

Enter Multi Router Traffic Grapher, or MRTG, an open source tool that creates graphs and Web pages based on SNMP information gathered from various network devices and servers. Almost any device with SNMP capability can be managed with the MRTG utility, and all of the information generated by MRTG is displayed through a Web browser. In this Daily Feature, I’ll explain the requirements for a successful basic installation and configuration of MRTG.

Requirements
To use MRTG, you should have a Web server, such as Apache or Netscape, running on your UNIX server. In addition, MRTG requires a number of free libraries such as gd and libpng to work properly. In most of the free versions of UNIX/Linux, these libraries are already installed, but in case you run into trouble, Table A provides a list of required libraries along with the locations from which they can be downloaded.
Table A
Required libraries for MRTG Required library Location to download from gcc gcc.gnu.org perl (5.005 or better) www.perl.com gd www.boutell.com/gd libpng www.libpng.org/pub/png/src zlib (ftp) sunsite.cnlab-switch.ch/mirror/infozip/zlib/ The list of required libraries for MRTG is a short one compared to some applications.

Installing MRTG
The first thing you’ll do is install the necessary libraries by following these steps:

1. 1. Create a directory for the compilation. (This directory may already exist on your system; if so, skip this step.)

mkdir -p /usr/local/src

1. 2. Change to the newly created directory:

cd /usr/local/src

1. 3. Install zlib with the following:

wget ftp://sunsite.cnlab-switch.ch/mirror...ib/zlib.tar.gz
gunzip -c zlib.tar.gz | tar xf -
mv zlib-?.?.?/ zlib
cd zlib
./configure
make
cd ..

1. 4. Install libpng by running the following:

wget http://www.libpng.org/pub/png/src/libpng-1.0.12.tar.gz
gunzip -c libpng-*.tar.gz |tar xf -
rm libpng-*.tar.gz
mv libpng-* libpng
cd libpng
make -f scripts/makefile.std CC=gcc ZLIBLIB=../zlib ZLIBINC=../zlib
rm *.so.* *.so
cd ..

1. 5. Install gd with the following:

wget http://www.boutell.com/gd/http/gd-1.8.3.tar.gz
gunzip -c gd-1.8.3.tar.gz |tar xf -
mv gd-1.8.3 gd
cd gd

1. 6. And finally, install the library directories with this command:

make INCLUDEDIRS="-I. -I../zlib -I../libpng" \
LIBDIRS="-L../zlib -L. -L../libpng" \
LIBS="-lgd -lpng -lz -lm"
cd ..
One line
The make command shown above that installs the library directories is actually one line with the backslash (\) characters representing no newline. (Leave those characters out of the command.)
Once all of the required libraries are installed, the installation of the MRTG program is very simple. The current version of MRTG is 2.9.17, and it’s available as mrtg-2.9.17.tar.gz. For this installation, please make sure that you’re logged in as a root user and that you place the MRTG installation file in /usr/local when you download it.

Once you’ve downloaded the distribution file, expand it by switching to the /usr/local directory with the cd /usr/local command and issuing the following at the command line:
gunzip –dc mrtg-2.9.17.tar.gz | tar xvf –

Next, switch to the mrtg source directory with the cd /usr/local/mrtg-2.9.17 command and run the configuration script with an option to install MRTG to the /usr/local/mrtg directory on your server by typing ./configure -–prefix=/usr/local/mrtg. This will only take a few seconds to run.

Next, you need to actually build the contents of MRTG. Type make at the command line and press [Enter]. Again, this will be quick. Finally, type makeinstall at the command line to install the MRTG binary files in their correct locations.

Configuring and running MRTG
The next step is to start giving MRTG configuration files for each device that you want it to monitor. MRTG comes with a utility written in Perl named cfgmaker (located in /usr/local/mrtg/bin in this example) that accomplishes this task automatically for you—automatic in the sense that you don’t have to type in a bunch of configuration commands. You still have to tell it which specific devices to monitor, though.

When you run cfgmaker, you must provide it with some basic details. First, give it a work directory, which is where it will store log files, generated graphs, and HTML output. This directory should be accessible to your Web server so that any HTML output can be rendered by a remote browser. Second, tell MRTG where and under what name to store the generated configuration file for a particular device. The configuration file contains static information that is consistent no matter what kind of traffic the device sees, such as system name, contact information, etc.

Once the configuration file is built, you can run the MRTG executable against it. The first couple of times that you run the MRTG executable file, you’ll get errors indicating problems with the log files. This is normal. MRTG expects to see a history of log files, and if you’ve never run it before, you won’t see these.

Sound complicated? It’s not too bad once you start using it. Another utility, indexmaker, creates a nice HTML index page for you, which is especially useful if you manage many devices. I’ll explain more about this one a little later.

An example will do a lot to clear up some of the confusion:

First, I’ll create the mrtg user with the command useradd mrtg. Then, I’ll run cfgmaker with these arguments to build an MRTG configuration file for a Windows 2000 server that is running the SNMP service. In this command, you can see that my work directory is /usr/local/apache/htdocs/mrtg. This is a directory that Apache can see, and it’s where MRTG will place log files, HTML files, and .png files for this device. I’m storing the configuration file in /home/mrtg as win2k.cfg.

Finally, notice that I’m using public@192.168.59.129 as the device name. Public is the SNMP read-only community name for this device, and the IP address is its address. (I don’t use DNS on my test network.)

After I run the command, the .cfg file is placed in /home/mrtg, but nothing is placed in the /usr/local/apache/htdocs/mrtg directory because I only built the MRTG configuration file for this device. I didn’t actually run MRTG yet to read any statistics.

Now I can run MRTG against this configuration file and see what happens:
/usr/local/mrtg/bin/mrtg /home/mrtg/win2k.cfg

I should see six files in the MRTG directory. The four files with .png extensions are graphs for day, month, week, and year. The purpose of the .log and .html files should be fairly evident.

Figure A

The MRTG initial analysis screen showing the default statistics

How did this work? If you examine the /home/mrtg/win2k.log file, you’ll notice a line marked WorkDir that points to this Apache directory. When you run MRTG, the contents of this .cfg file are analyzed and used as parameters for the program. Figure A shows what appears when I browse to the file http://192.168.59.128/mrtg/192.168.59.129_2.html.
Options
As you can see, the default statistics offer Max In/Out, Average In/Out, and Current In/Out. Naturally, you can add many more options to the graphing of your network. If you’re interested in using MRTG to monitor more than the basics, take a look at this MRTG Site guide that will give you a listing of how various sites are using MRTG and how they modify MRTG to suit their needs.

Figure B

Our networking is peaking at nearly 960 Kbps.

The graphs are unpopulated because I just ran the MRTG program for the first time, and the lab server that I use had no traffic. Figure B is a look at the daily graph a few minutes later.

To gather statistics on a periodic basis, you need to either run MRTG from the command line manually or you must find a way to automate the process. Personally, I’d rather automate it. You can use a cron job to do this.

I added the line */5 * * * * /usr/local/mrtg/bin/mrtg /home/mrtg/win2k.cfg to root’s crontab file by running the crontab –e command as the root user. Now, every five minutes, MRTG will be automatically run against the configuration file created earlier.

Multiple interfaces and multiple systems
Most routers and switches have more than one interface. With MRTG, you can separately monitor each one. In this example, I’ll monitor the ports on my Cisco PIX firewall for activity.

Creating the configuration file for a device with multiple interfaces is just as easy as it was in the last example. My particular device’s SNMP community string is public, and its inside IP address is 172.16.1.1. To create the configuration file for this device, I’ll issue this command.

Next, I run MRTG against this file to create an initial set of statistics by issuing /usr/local/mrtg/bin/mrtg /home/mrtg/fw.cfg at the command line. I’ll add this device to the crontab file so that MRTG is automatically run every five minutes.

When I want to view the statistics that were just created, I can browse to it, as before, and use the notation <SNMP device IP address>_<interface number>.html to view statistics on the device. In my case, since the firewall I’m monitoring has only two interfaces, I can view two HTML files, 172.16.1.1_1.html and 172.16.1.1_2.html, depending on which interface I want to see.

The index maker tool
If you think it seems like it can be a little cumbersome to view statistics, you’re correct. But the brains behind MRTG thought it out for you and packaged MRTG with an index creation tool that allows you to see all the devices you’re monitoring at a glance and choose the one you’re interested in.

You’ll find the index maker tool at /usr/local/mrtg/bin/indexmaker. To use indexmaker, you need to give it at least two parameters. The first one is a –output parameter, which tells the utility where to place the results. The second required parameter is the .cfg file that the utility should index. In this example, I’ll index the win2k.cfg and the fw.cfg files that were generated earlier and place the output in the same location as the MRTG files.



If I looked at the fw.html file with my browser, I’d see a screen similar to that in Figure C. Notice that this is an overall traffic analysis for each port on the device rather than four separate graphs broken down by time increments.

Figure C

If you were to click on one of the graphs shown, you would get the full statistical results for that port.

Next, I can create an index.html file that points to each of these two files. In a small environment, you may not need to create this index, but as you add more devices to be monitored by MRTG, I’m sure that you’ll find this utility to be an invaluable resource.

For these two devices, I could create an index.html file in the /usr/local/apache/htdocs/mrtg folder that looks like this:
<HTML>
<BODY>
<A HREF="fw.html">PIX firewall stats</A><BR>
<A HREF="win2k.html">Windows 2000 Server</A>
</BODY>
</HTML>

As you add new devices, you can add links to the appropriate indexmaker output file so that you have a “one-stop shop” for all of your network-monitoring needs.

Conclusion
Without the aid of a network-monitoring tool like MRTG, troubleshooting your network would be infinitely more difficult. With MRTG’s ability to give constant Net traffic updates, it’s possible to see, in real time, where your networking issues lie. I’ve gone over the very basic installation and simple configuration of a free tool that will allow you to watch your network devices and get statistical information from them at a glance. MRTG has been around for a number of years and will likely be around for many more as improvements are made. Naturally, because it’s an open source project, you can send your suggestions and alterations to the creator to help mold this into the perfect tool for the professional IT network administrator.

In my next article, I’ll discuss another open source monitoring package, Big Brother, and explain how it can be used with MRTG as a very effective monitoring suite.
Have a cool Linux tool?
Do you have a particular Linux tool that you’d like to see covered on TechProGuild? If so, send an e-mail to Jack Wallen, Jr., and let him know what it is

[patris1]

http://articles.techrepublic.com.com/5100-22_11-5139492.html?tag=rbxccnbtr1

Takeaway: MRTG is a great Linux utility to help monitor your network. Ron Nutter shows how you can bring this free tool to your Windows network.
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.

What's MRTG?
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.

Installing MRTG
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 snmp_community@10.1.1.1 –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 snmp_community@10.1.1.1. 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

[patris1]

http://articles.techrepublic.com.com/5100-10878_11-6130300.html?tag=rbxccnbtr1

Takeaway: With MRTG you can graph your network traffic, but you can also use it to gather other network information, such as monitoring your system's swap and memory usage. Vincent Danen shows you how to get more out of MRTG in this tip.

MRTG is useful for more than just graphing network traffic. If you look at the MRTG Companion Sites page, you'll see numerous links to different scripts and tools to put all kinds of information into an MRTG graph.
Here, we will look at monitoring the local system's swap and memory usage over time. This assumes that MRTG is already configured or you have an understanding of how to configure MRTG (see this former tip).
The first step is to create the script, which is very simplistic. Save it as /usr/local/bin/memstat.sh with the following contents:
#!/bin/sh/usr/bin/free -b | /bin/awk '\NR==2 {ramUsed = $3 }\NR==4 {swapUsed = $3 }\END { print swapUsed "\n" ramUsed "\n0\n0" }' The output, for a human, is not very interesting:
# /usr/local/bin/memstat.sh 0154800947200 For MRTG, however, with the appropriate configuration, it becomes very interesting. Add the following snippet to /etc/mrtg.cfg. Ideally, MRTG should be running every five minutes for a good sampling.
Target[localmem]: `/usr/local/bin/memstat.sh`Title[localmem]: Mem and Swap Usage [surtr]PageTop[localmem]: <h1>Memory and Swap Usage [surtr]</h1>MaxBytes[localmem]: 100000000000ShortLegend[localmem]: BYLegend[localmem]: MemoryLegendI[localmem]: SwapLegendO[localmem]: MemLegend1[localmem]: SwapLegend2[localmem]: MemOptions[localmem]: gauge,growright,nopercentkMG[localmem]: k,M,G,T,P,XColours[localmem]: RED#bb0000,BLUE#1000ff,GREEN#006600,VIOLET#ff00ff This code tells MRTG to execute the /usr/local/bin/memstat.sh script and take the numbers it provides as output as input for itself, which will then be used to create a typical MRTG graph of the data. This will then give you a sampling of memory and swap usage over time. MRTG will create graphs for yearly, monthly, weekly, and daily statistics.
Using the same, you could perform the same data analysis for CPU usage, disk usage, e-mail statistics, Web traffic, and much more

[patris1]

http://articles.techrepublic.com.com/5100-10878_11-5032640.html?tag=leftCol%3barticleText

Takeaway: A good network monitoring tool is worth its weight in IP addresses. Unfortunately, most tools can't be customized to fit your needs. With the RRDtool, you can monitor darn near anything. Scott Lowe will help you get it up and running.

The Round Robin Database Tool (RRDtool), created by Tobias Oetiker, the author of the Multi Router Traffic Grapher (MRTG), is a system to store and display data. As stated on the RRDtool Web page, it can be thought of as a replacement for MRTG’s graphing and logging features. You can think of this utility as a replacement on steroids.
MRTG
Need more information on MRTG? Don’t forget to take a look at Scott Lowe’s "Graph and watch your network with MRTG 2.9.17."
MRTG’s original database design is rather inefficient because it allows the database to grow larger and larger over time, resulting in a loss of performance and an increase in storage requirements. RRDtool uses a much more efficient method of storing data. A specific number of data points are allotted at the time that the database is created. When these fill up, one is reused, thus saving space in the database. While this makes it sound as if data will be lost once the database fills up, that’s not the case. For example, those of you using MRTG are familiar with the daily and weekly graphs. If you use RRDtool, once the daily data points are used up, an average is taken and used for the weekly data point, and then the daily data points are reused.

In this Daily Drill Down, I’ll discuss RRDtool as it pertains to replacing the graphing component of the MRTG network-monitoring package. For my example, I’ll download RRDtool and another utility, routers.cgi, that will act as the front-end component to the new system. When I’m done, I’ll have the following:

• · Data collection by MRTG (stored in an RRD database)
• · Graphs generated from this RRD database by RRDtool
• · A front end for a Web browser using routers.cgi

Get it and install it
You can get RRDtool from the RRDtool Web site. Download the tar’d and zipped file called rrdtool-1.0.33.tar.gz. This is version 1.0.33, which is the latest stable release (as of this writing); version 1.1 is available for a sneak preview via CVS.
CVS
Interested in giving CVS a go? Take a look at Vincent Danen’s series on CVS: "Source Code Management: Installing CVS," "Checking it out: CVS!," and "More control with CVS."
If you’re going to follow along with this example, before you begin, make sure that you have at least Perl 5.004 installed, or RRDtool won’t function.
Distribution?
I’m running on a Red Hat 7.1 installation on standard hardware, with a mostly default installation.
I’m going to go through the installation of RRDtool very quickly because it’s very straightforward and like almost any other source distribution installation. To properly follow these installation instructions, you should save the gzipped tarball into the /usr/local directory of your server and make sure that you’re a root user. Once this is done, run the following commands:
cd /usr/local
gunzip –dc rrdtool-1.0.33.tar.gz | tar xvf –
cd rrdtool-1.0.33
./configure –prefix=/usr/local/rrdtool
make
make install

Note that the make process takes quite some time to complete. Once the above steps are complete, you’ll have a fully functioning copy of RRDtool in /usr/local/rrdtool.

Integrating RRDtool with MRTG
While RRDtool can be used to graph any time-sensitive data that you deem fit, I’m going to concentrate on how RRDtool can enhance the use of MRTG and make use of the very well-written and comprehensive front end, routers.cgi.

You’ll see some major changes by the time you’re finished with this Daily Drill Down. First of all, MRTG will no longer generate any graphs whatsoever. None. MRTG will become nothing more than a data-collection engine. RRDtool will handle all the graphing work, and the presentation will be done by yet another program.

What good is this? First, the overhead of having graphs created at each and every MRTG update interval is removed. Graphs will only be created when they’re requested, saving CPU cycles. Second, you’ll end up using the round robin database format, which is much more efficient than the native MRTG database format. And you can use any front end you wish. If you get through this Daily Drill Down and don’t like what you see, you can create your own front end or find a different one.
Note
A default MRTG installation uses the rateup tool to create the graphs that you see.
I’ll assume that you have a working copy of MRTG installed and configured and that you have a target that is being actively monitored. For this example, I’ll be monitoring a Zyxel DSL router. If you don’t have MRTG installed and configured or you’re not monitoring a specific target, please read my previous article on that subject, "Graph and watch your network with MRTG 2.9.17," and get to this point before continuing.

Let’s put all the RRD configuration files in a config directory under MRTG:
mkdir /usr/local/mrtg/config

The next step in this process is to copy the configuration file that you wish to convert from the MRTG rateup tool to RRDtool. My MRTG configuration file for my DSL router is /home/mrtg/zyxel.cfg, which I’ll copy to /home/mrtg/rrdzyxel.cfg with this command:
cp /home/mrtg/zyxel.cfg /usr/local/mrtg/config/rrdzyxel.cfg

Now, I need to modify this configuration file so that it knows where to find RRDtool and certain libraries, and I must tell it which log format to use.

At the top of my /usr/local/mrtg/config/rrdzyxel.cfg file, I’ll put the following statements (I use pico for a text editor):
PathAdd: /usr/local/rrdtool/bin/
LibAdd: /usr/local/rrdtool/lib/perl/
LogFormat: rrdtool

Once this is done, I need some way to actually view the graphs. As stated, it offers an improved database format and a lot of graphing options, but RRDtool doesn’t generate graphs unless a front end asks it to. Luckily, folks out there have done a huge amount of work and created some very good scripts to do this for you. For this Daily Drill Down, I’ll download a set of scripts from Steve’s Web Applications. Table A lists files that you can download from this site. I’ll concentrate on the routers scripts, but the others are also quite useful.

Table A Filename Version Description http://www.cheshire.demon.co.uk/pub/routers-v1.30.tar 1.30 A set of CGI scripts for monitoring routers with MRTG and RRDtool – written in Perl http://www.cheshire.demon.co.uk/pub/servers-v1.0.tar 1.0 A set of CGI scripts and agents that are used to monitor servers with MRTG and RRDtool http://www.cheshire.demon.co.uk/pub/generic-v0.13.tar 0.13 beta This set of CGI scripts is designed to replace the 14all set of CGI scripts, which was the first front end developed for RRDtool.

When you download these files, save them to /usr/local. Next, create a directory called rrdscripts in /usr/local:
mkdir /usr/local/rrdscripts

Switch to this directory and expand the routers-v1.30.tar file that was downloaded in the previous step:
cd /usr/local/rrdscripts
tar –xvf /usr/local/routers-v1.30.tar

This set of scripts has a number of dependencies. If you’re closely following the instructions in this article and the article on installing MRTG, the MRTG/RRDtool parameters should be fine. If you’re running on a fairly recent, standard installation of UNIX or Linux, the built-in installation script should work fine, as well. However, if you’re running something unusual, you may need to make adjustments to your installation to make everything work. Refer to the documentation that came with the program for details if you run into trouble.

To install this set of scripts, do the following:
cd /usr/local/rrdscripts/routers-v1.30
perl install.pl

Run it, and you’ll see this.

When you press [Enter], you’ll see this.

In step 0, no user input is required because the install script will automatically detect what your OS is and where you have your Web server installed. Step 1 asks for the location of your Web server’s document directory. In my installation of Apache, it’s /usr/local/apache/htdocs. Along the same lines, in step 2, you’re asked for your Web server’s cgi-bin directory.

In the MRTG installation that I walked through in my previous article, I used the MRTG user’s home directory as the location for scripts (step 3). This directory is /home/mrtg. Earlier in this article, I copied my zyxel.cfg configuration file to rrdzyxel.cfg. I’ll continue to use this naming convention, so I’ll tell the RRDtool installer that any configuration file starting with rrd is fair game (step 4).

In step 5, I plan to keep my RRD files under the Apache directory to prevent permission problems. Where is Perl? Step 6 shows that I’m configuring it for /usr/bin/perl on my system. Step 7 allows me to tell the system where I would like to have the configuration file for this program stored.

The following section will ask a rather confusing question.

Since this is very poorly documented and described, we’ll use mixed; it’s the default, and I don’t have a better reason than that.
INSTALLING SOFTWARE

We’re almost done.
Perl is : /usr/bin/perl
MRTG files : /usr/local/mrtg/config/*.cfg
…
…
** ALL COMPLETE **

And finally, a bit of installation information is shown:
The routers cgi files are now installed and ready to use!

Let’s see what we have
You should wait 10 or 15 minutes to allow MRTG and RRDtool to actually gather some statistics. Also, if you’re converting from an MRTG installation that has a large amount of data, you may need to wait while RRDtool converts it.

Using a java-enabled browser that allows cookies, browse to http://<your_server>/cgi-bin/routers.cgi (where your_server is the actual address of the server being used). When you get there, you’ll get the introduction screen for the Router Monitor, as shown in Figure A.

Figure A

The Router Monitor initial screen is showing very little traffic.

On the left side of the screen, you’ll see an Options button and a list of configuration files under Routers. For this example, I only have one file, rrdzyxel.cfg.

If you click on Options, you’ll be presented with a whole host of options with different ways to look at your data. You’ll notice that the graphs are slightly different than the ones produced with the MRTG rateup tool. By default, the RRDtool utility puts a red line at the top of the initial graphs indicating the maximum speed for that interface.

Let’s look at a specific difference. Want to see a graph that has a line for each and every interface in your router, along with maximum, average, and current statistics, but only for outgoing data? Okay. Click on Options | Outgoing and take a look at the results.

Figure B

Graphing router traffic for all ports

In Figure B, you can see some traffic for two ports on my DSL router and statistics for these ports. The remaining ports aren’t active.

We’re finished with the first configuration file. Now it’s time to do the rest. I recommend copying all of your configuration files to a new location and then rerunning the install.pl script that came with the routers.cgi package, so that they’re all converted and available at once. Don’t forget to modify the copied configuration files before you rerun the install.pl scripts. Each one needs to have the three lines at the top of the script modified to add path information and library location and to be told to use RRD rather than rateup.

An actual use of RRDtool from the Web
RRDtool can measure just about anything. While graphs in MRTG can be slightly customized, that’s nothing compared to what can be done with RRDtool. As an example of just how customized a graph in RRDtool can be, take a look at Figure C, which is from the RRDtool sample image gallery showing line usage at an ISP. Included in this graph are lines for the points at which the ISP imposes additional fees. The user of this graph created it to be able to verify and estimate the bill from his ISP. The graph was created with a fairly complex script, which I’ll also show you.

Figure C

A typical ISP billing graph from RRDtool

As you can see, the graph has been heavily customized to fit the needs of this user and contains quite a lot of information in a surprisingly easy-to-read format. This script generated the graph. It’s available in the public domain and was written by Alex van den Bogaerdt, who has also authored at least two tutorials on the use of RRDtool.

Conclusion
Switching from using the rateup tool to RRDtool databases in MRTG serves a number of purposes, including better speed, better graphs, and the use of a number of tools, such as the routers.cgi tool, that create a full monitoring environment.

I like the RRDtool approach because it makes the network-monitoring tool more componentized. I can use any utility I want to get the data and anything that I want to view it.

If you look around the Net a bit, you’ll also see that RRDtool is used by folks to track the space shuttle, look at the weather, and more. It’s useful for much more than gathering network statistics.

I recommend that you look around the Web for other uses of RRDtool or learn to create your own RRDtool applications.

I hope that this Daily Drill Down was helpful in exposing you to RRDtool and how it can be used to interact with MRTG

[patris1]

https://lists.oetiker.ch/pipermail/mrtg/2003-December/026588.html

I use srvany.exe and instrv.exe from the resource kit to make MRTG run on
all my servers.

Make sure your MRTG conf includes the line:
RunAsDaemon: Yes

Create a bat file with 1 line:
Perl mrtg mrtg.cfg

Save it to your MRTG \bin folder

Copy srvany.exe and instsrv.exe into the \winnt directory

Open a cmd window and type:
Instrv MRTG srvany

Modify this to your exact install point:

<REG File Start>

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\MRTG]
"Type"=dword:00000010
"Start"=dword:00000002
"ErrorControl"=dword:00000001
"ImagePath"=hex(2):73,00,72,00,76,00,61,00,6e,00,7 9,00,00,00
"DisplayName"="MRTG"
"DependOnService"=hex(7):54,00,63,00,70,00,69,00,7 0,00,00,00,00,00
"DependOnGroup"=hex(7):00,00
"ObjectName"="LocalSystem"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\MRTG\Parameters]
"Application"="D:\\mrtg-2.9.27\\bin\\mrtg.bat"
"AppDirectory"="D:\\mrtg-2.9.27\\bin\\"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\MRTG\Security]
"Security"=hex:01,00,14,80,a0,00,00,00,ac,00,00,00 ,14,00,00,00,30,00,00,00,0
2,\

00,1c,00,01,00,00,00,02,80,14,00,ff,01,0f,00,01,01 ,00,00,00,00,00,01,00,00,\

00,00,02,00,70,00,04,00,00,00,00,00,18,00,fd,01,02 ,00,01,01,00,00,00,00,00,\

05,12,00,00,00,74,00,69,00,00,00,1c,00,ff,01,0f,00 ,01,02,00,00,00,00,00,05,\

20,00,00,00,20,02,00,00,76,00,65,00,00,00,18,00,8d ,01,02,00,01,01,00,00,00,\

00,00,05,0b,00,00,00,20,02,00,00,00,00,1c,00,fd,01 ,02,00,01,02,00,00,00,00,\

00,05,20,00,00,00,23,02,00,00,76,00,65,00,01,01,00 ,00,00,00,00,05,12,00,00,\
00,01,01,00,00,00,00,00,05,12,00,00,00

</REG FILE END>

Cut and paste that into a text file, save as MRTG.reg
Double click on the file and say yes to the import.

Go to services and change the startup account from System to an account with
Admin Rights
Start MRTG service

[patris1]

http://blogs.uct.ac.za/blog/daves-blog/2009/03/02/monitoring-apache-connections-and-proceses-with-mrtg

When running web based applications with Apache as a front end it is useful to monitor the number of connections on Apache and number of Apache processes. Under certain conditions Apache can spawn extra proccesses and many of theem indicated reduced QOS for your end users. They include:

1. The back end aplication taking too long to process requests
2. network related problems
3. resource contention on the box hosting Apache.

Its pretty easy to monitor this using MRTG. First a simple perl script:

#! /usr/bin/perl

use strict;

my $connections = `netstat -n | grep EST | grep "137.158.155.8:443 " | wc -l`;
my $processes = `ps ax | grep -c httpd`;

chomp($connections);
chomp($processes);

print $connections . "\n";
print $processes . "\n";

Edit the ip address to match your host. This will give you a count of connections and processes. Next the MRTG conf:

# Created by
# /usr/local/bin/cfgmaker public@localhost

### Global Config Options

#  for UNIX
WorkDir: /srv/www/vhosts/vula.uct.ac.za/mrtg/
IconDir: /mrtg/icons/

### Global Defaults

#  to get bits instead of bytes and graphs growing to the right
Options[_]: growright, noinfo, nopercent, integer, gauge

EnableIPv6: no

### Interface 1 >> Descr: 'em0' | Name: '' | Ip: '137.158.128.44' | Eth: '' ###

MaxBytes[_]: 4061814272
ShortLegend[_]:  
YLegend[_]: https connections
AddHead[_]: <link href="/library/skin/default/tool.css" type="text/css" rel="stylesheet" media="all" />
PageFoot[_]: </div>
kilo[_]: 1024

Target[https-connections]: `/usr/local/sakaiscripts/https-connections.pl`
Title[https-connections]: HTTPS Connections
PageTop[https-connections]: <div class="portletBody"><H3>HTTPS Connections</H3>
LegendI[https-connections]: &nbsp;connections:
LegendO[https-connections]: &nbsp;httpd processes:
Legend1[https-connections]: HTTPS connections (5 min interval)
Legend2[https-connections]: httpd processes
Legend3[https-connections]: Maximal HTTPS connections (5 min interval)
Legend4[https-connections]: Maximal httpd processes
WithPeak[https-connections]: wmy

once again make sure the WorkDir and traget paths match the paths for your instalation. Workdir needs to be accesible via a browser (as MRTG will output to this directory). Now test your script by running:
env LANG=C /usr/bin/mrtg /usr/local/sakaiscripts/https-connections.cfg
Note MRTG will give warnings about the history files missing the first two times you run it. After that it should be silent. Finaly add the line to your crontab to run every 5 minute

[patris1]

http://net-snmp.sourceforge.net/tutorial/tutorial-5/mrtg/index.html

This page will present a few ideas of what you can monitor on your hosts with the net-snmp using the mrtg utility.
This is not an MRTG tutorial, and it is not going to talk about monitoring network traffic.
Note, that these examples uses values that are only available from net-snmp-4.2 or above and that the LoadMIBs mrtg directive requires mrtg-2.8.0.

Monitoring CPU load

There are several ways to try to monitor CPU usage, because the system maintains several CPU counters: Idle, System, User, Nice. As MRTG does not allow you to graph more than two values at a time, it is possible to select any two values ang graoh aginst each other, but it it also possible to compute a combined value.

User vs Idle CPU usage

An example of such a graph is here. The corresponding MRTG configuration is

LoadMIBs: /usr/local/share/snmp/mibs/UCD-SNMP-MIB.txt

    Target[kontor.cpu]:ssCpuRawUser.0&ssCpuRawIdle.0:public@10.10.11.2
    RouterUptime[kontor.cpu]: public@10.10.11.2
    MaxBytes[kontor.cpu]: 100
    Title[kontor.cpu]: CPU LOAD
    PageTop[kontor.cpu]: <H1>User CPU Load %</H1>
    Unscaled[kontor.cpu]: ymwd
    ShortLegend[kontor.cpu]: %
    YLegend[kontor.cpu]: CPU Utilization
    Legend1[kontor.cpu]: User CPU in % (Load)
    Legend2[kontor.cpu]: Idle CPU in % (Load)
    Legend3[kontor.cpu]:
    Legend4[kontor.cpu]:
    LegendI[kontor.cpu]:  User
    LegendO[kontor.cpu]:  Idle
    Options[kontor.cpu]: growright,nopercent

User vs System CPU usage

An example of such a graph is here. The corresponding MRTG configuration is

LoadMIBs: /usr/local/share/snmp/mibs/UCD-SNMP-MIB.txt

    Target[kontor.usrsys]:ssCpuRawUser.0&ssCpuRawSystem.0:public@10.10.11.2
    RouterUptime[kontor.usrsys]: public@10.10.11.2
    MaxBytes[kontor.usrsys]: 100
    Title[kontor.usrsys]: CPU LOAD
    PageTop[kontor.usrsys]: <H1>CPU (user and system) Load %</H1>
    Unscaled[kontor.usrsys]: ymwd
    ShortLegend[kontor.usrsys]: %
    YLegend[kontor.usrsys]: CPU Utilization
    Legend1[kontor.usrsys]: User CPU in % (Load)
    Legend2[kontor.usrsys]: System CPU in % (Load)
    Legend3[kontor.usrsys]:
    Legend4[kontor.usrsys]:
    LegendI[kontor.usrsys]:  User
    LegendO[kontor.usrsys]:  System
    Options[kontor.usrsys]: growright,nopercent

Active CPU usage

An example of such a graph is here. This example sums User, System and Nice and plots it as a single value. The corresponding MRTG configuration is

LoadMIBs: /usr/local/share/snmp/mibs/UCD-SNMP-MIB.txt

    Target[kontor.cpusum]:ssCpuRawUser.0&ssCpuRawUser.0:public@10.10.11.2 + ssCpuRawSystem.0&ssCpuRawSystem.0:public@10.10.11.2 + ssCpuRawNice.0&ssCpuRawNice.0:public@10.10.11.2
    RouterUptime[kontor.cpusum]: public@10.10.11.2
    MaxBytes[kontor.cpusum]: 100
    Title[kontor.cpusum]: CPU LOAD
    PageTop[kontor.cpusum]: <H1>Active CPU Load %</H1>
    Unscaled[kontor.cpusum]: ymwd
    ShortLegend[kontor.cpusum]: %
    YLegend[kontor.cpusum]: CPU Utilization
    Legend1[kontor.cpusum]: Active CPU in % (Load)
    Legend2[kontor.cpusum]:
    Legend3[kontor.cpusum]:
    Legend4[kontor.cpusum]:
    LegendI[kontor.cpusum]:  Active
    LegendO[kontor.cpusum]:
    Options[kontor.cpusum]: growright,nopercent

Monitoring DISK space

There are two tables that can be used when monitoring disk space, UCD-SNMP-MIB:dskTable and HOST-RESOURCES-MIB:hrStorageTable. There are two noticeable differences bwtween these tables: UCD-SNMP-MIB:dskTable requires a configuration directive in snmpd.conf, but it also gives a direct measure of the percentage of free space
On the system I used for these examples, I have the following disks:

 $ df
    Filesystem            Size  Used Avail Use% Mounted on
    /dev/hda6             289M   56M  218M  21% /
    /dev/hda1             7.3G  3.2G  4.1G  44% /mnt/windows
    /dev/hda7             1.7G  1.2G  429M  74% /usr
    /dev/hdc1              19G  6.7G   11G  37% /space

and I have put the following lines into snmpd.conf:

 disk    /    100000
    disk    /usr    100000
    disk    /space    100000

Monitoring from dskTable

I used the direct percentage of disk full for the root and /usr partitions in this example It plot the usage of the root and the /usr partitions in one graph.

LoadMIBs: /usr/local/share/snmp/mibs/UCD-SNMP-MIB.txt

    Target[kontor.root]:dskPercent.1&dskPercent.2:public@10.10.11.2
    RouterUptime[kontor.root]: public@10.10.11.2
    MaxBytes[kontor.root]: 100
    Title[kontor.root]: DISK USAGE
    PageTop[kontor.root]: <H1>DISK / and /usr Usage %</H1>
    Unscaled[kontor.root]: ymwd
    ShortLegend[kontor.root]: %
    YLegend[kontor.root]: DISK Utilization
    Legend1[kontor.root]: Root disk
    Legend2[kontor.root]: /usr disk
    Legend3[kontor.root]:
    Legend4[kontor.root]:
    LegendI[kontor.root]:  Root disk
    LegendO[kontor.root]:  /usr disk
    Options[kontor.root]: growright,gauge,nopercent

Monitoring from hrStorageTable

Use of hrStorageTable requires no preceding configuration, as in this example It plot the partition size as one value, and the used space as another. Note:the values returned here are in units of hrStorageUnits, which, dependent on the file system type, may or may not be 1K.

 LoadMIBs: /usr/local/share/snmp/mibs/HOST-RESOURCES-MIB.txt

    Target[kontor.hrroot]:hrStorageSize.1&hrStorageUsed.1:public@10.10.11.2
    RouterUptime[kontor.hrroot]: public@10.10.11.2
    MaxBytes[kontor.hrroot]: 300000
    Title[kontor.hrroot]: DISK / USAGE
    PageTop[kontor.hrroot]: <H1>DISK / Usage</H1>
    ShortLegend[kontor.hrroot]: B
    kMG[kontor.hrroot]: k,M,G,T,P
    kilo[kontor.hrroot]: 1024
    YLegend[kontor.hrroot]: DISK / Utilization
    Legend1[kontor.hrroot]: Root disk size
    Legend2[kontor.hrroot]: Root disk usage
    Legend3[kontor.hrroot]:
    Legend4[kontor.hrroot]:
    LegendI[kontor.hrroot]:  Root disk size
    LegendO[kontor.hrroot]:  Root disk usage
    Options[kontor.hrroot]: growright,gauge,nopercent

Two further examples that have been offered:

Monitoring TCP connections

 Target[tcpopen]: 
    .1.3.6.1.2.1.6.9.0&.1.3.6.1.2.1.6.9.0:public@localhost 
    Options[tcpopen]: nopercent,growright,gauge,noinfo 
    Title[tcpopen]: Open TCP connections 
    PageTop[tcpopen]: Open TCP connections
    MaxBytes[tcpopen]: 1000000 
    YLegend[tcpopen]: # conns 
    ShortLegend[tcpopen]: connections 
    LegendI[tcpopen]:  Connections: 
    LegendO[tcpopen]: 
    Legend1[tcpopen]: Open TCP connections

and

Monitoring Free Memory

 Target[freemem]: 
    .1.3.6.1.4.1.2021.4.11.0&.1.3.6.1.4.1.2021.4.11.0:public@localhost 
    Options[freemem]: nopercent,growright,gauge,noinfo 
    Title[freemem]: Free Memory 
    PageTop[freemem]: Free Memory
    MaxBytes[freemem]: 1000000 
    kMG[freemem]: k,M,G,T,P,X 
    YLegend[freemem]: bytes 
    ShortLegend[freemem]: bytes 
    LegendI[freemem]:  Free Memory: 
    LegendO[freemem]: 
    Legend1[freemem]: Free memory, not including swap, in bytes