home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam  

Book HomeEssential SNMPSearch this book

5.4. Trend Analysis

When faced with most network problems, it's nice to have some kind of historical record to give you an idea of when things started going wrong. This allows you to go back and review what happened before a problem appeared, and possibly prevent it from recurring. If you want to be proactive about diagnosing problems before they appear, it is essential to know what "normal" means for your network -- you need a set of baseline statistics that show you how your network normally behaves. While many of the bigger packages do some trend reporting, they can be clunky and hard to use. They might not even provide you with the kind of information you need. Once you see what a dedicated trend-analysis system can do, you will see why it might be worth the time, energy, and money to integrate one into your network-monitoring scheme.

If your environment calls for some serious monitoring, you should look into getting RMON probes. RMON probes are a great addition to trend-analysis packages, since most trend packages can make use of the kind of data these probes gather. The rest of this section lists some trend-analysis packages.

Trinagy (Formerly DeskTalk Systems, Inc.) TRENDhttp://www.desktalk.com


Unix, Windows 9x/NT


An excellent product for use in capacity planning. Out of the box, Trinagy supports 30, 60, and 90-day forecasts, among other calculations. Its report viewer is written in Java, so it is usable on most platforms. The report architecture is open, in that you can build your own reports.


Requires two weeks of training to run and administer. The pricing scheme is somewhat similar to eHealth's, since the size of the database depends on how many devices you query, how long you keep rate data around, etc. You can get more for less by tweaking polling intervals and retention times.



Most Unix platforms, Windows NT


Free, easy to set up and use, very well documented. In addition to polling devices on your network, MRTG can receive input from non-SNMP sources.


Have to install multiple packages, which may be difficult to do on some platforms. For example, MRTG needs a specific SNMP Perl module to perform all of its polling duties. Not very scalable.

Library Navigation Links

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