UNIX System Administration Handbook - Evi Nemeth [383]
interfaces.ifTable.ifEntry.ifInErrors.1 = 0
interfaces.ifTable.ifEntry.ifInErrors.2 = 218
interfaces.ifTable.ifEntry.ifOutOctets.1 = 12591593
interfaces.ifTable.ifEntry.ifOutOctets.2 = 3374588125
...
In this example, we see some general information about the system, followed by statistics about the host’s network interfaces, lo0 and eth0. Depending on the MIBs supported by the agent you are managing, a complete dump can run to hundreds of lines.
MRTG: the Multi-Router Traffic Grapher
MRTG, written by Tobi Oetiker at ETH in Zurich, collects SNMP data over time and then graphs it. It’s written mostly in Perl. MRTG is invaluable for analyzing the historical use of your system and network resources.
MRTG runs regularly from cron and can collect data from any SNMP source. Each time the program runs, new data is stored and new graph images are created.
MRTG is free and offers several attractive features. First, it maintains a zero-maintenance, statically-sized database; the software stores only enough data to create the necessary graphs. For example, MRTG could store one sample every minute for a day, one sample every hour for a week, and one sample every week for a year. This consolidation scheme lets you maintain important historical information without having to store unimportant details or to consume your time with database administration.
Second, MRTG can record and graph any SNMP variable. You’re free to collect whatever data you want. When combined with the UCD SNMP agent, MRTG can provide a historical perspective on almost any system or network resource.
Exhibit A on the next page shows some examples of the graphs created by MRTG. These graphs show the traffic on a network interface over periods of a day and a week.
Exhibit A Examples of MRTG graphs
The future of MRTG lies in a new package, RRDtool, by the same author. RRDtool is similar in concept to MRTG, but with improved data consolidation and graphing features. Unlike MRTG, RRDtool does not offer any data collection methods of its own. Instead, a separate piece of software must collect the data.
Currently, Jeff Allen’s Cricket tool is the best choice for this role. Cricket is not limited to collecting SNMP data; it can pull in data from almost any network source. Since it is written in Perl, it’s easy to add new data sources.
Tobi Oetiker’s home page at ee-staff.ethz.ch/~oetiker provides links to the current versions of MRTG, RRDtool, and Cricket.
NOCOL: Network Operation Center On-Line
NOCOL is an event-driven management tool that’s currently maintained by Vikas Aggarwal. Although it will not help you determine how much your bandwidth utilization has increased over the last month, it will page you when your web server goes down. Actually, NOCOL can be configured to page (or email) your operations staff after many kinds of events.
The distribution includes monitor programs that supervise a variety of common points of failure. You can whip up new monitors in Perl, or even in C if you are feeling ambitious. For notification methods, the distribution can send email, generate web reports, view status with a curses interface, and use a dial-up modem to page you. As with monitor programs, it’s easy to roll your own.
If you cannot afford a commercial network management tool, we suggest giving strong consideration to NOCOL. The software works very well for networks of less than 100 hosts and devices. You can read more at www.netplex-tech.com.
Commercial management platforms
Hundreds of companies sell network management software, and new competitors enter the market every week. Instead of recommending the hottest products of the moment (which may no longer exist by the time this book is printed), we’ll try to identify the features you should look for in a network management system.
Data gathering flexibility:It’s important for management tools to be able to collect data from sources other than SNMP. Many packages include the ability to gather data from almost any network service. For example, some packages can