[mrtg] Re: MRTG management

[bwoodcoc]

Hi Doug,

Hmm, this may take a bit of typing. Our scope is 4-500 switches and about 
120 routers. Total interconnections are around 800-1000 interfaces for 
collection is my best guess (but no stats on user ports). We are using mrtg 
with rrd's and 14all.

A cfgmaker like process is run daily to keep all configs up to date and 
fairly dynamic (run on the fly if needed). Configs are broken into 4 
directories for routers, switches, networks (dummy configs for navigation), 
and interfaces which is on the fly dummy configs also.

The rrd's are stored as such under apache htdocs: L3/<rtrName>/*.rrd and 
also L2/<sw_ip>/*.rrd . We are keeping utilization and ifErrors/ifDiscards 
on every interconnectivity interface. We also collect response time 
(*distributed*) for across every point to point link (some things I think 
you still can't buy). Thresholds on everything with alarms going to a 
central web based alarm manager.

Navigation comes in multiple forms.

1. A small cgi (so it's dynamic) lists out either all the routers or all 
the switches. These lists are text hot linked to a bridge script which 
calls 14all with a pointer to the cfg and the rrd. Simple, reliable, but 
not flashy at all.

2. The alarms on the web page have a hot link to the cgi which calls 14all. 
So we have an alarm manager displaying any issue and one click to view 
metrics for that condition.

3. Metrics are exported to csv files every 5 minutes. A topN script can be 
run which can sort this stuff multiple ways and there are hot links which 
again point to the cgi which calls 14all from the listing.

4. I have scripts which auto-maps all this topology and use this as 
graphical navigation to mrtg data. It looks like a visio topology drawing 
of sorts and for cisco running native ios it is an integrated Layer2/Layer3 
drawing. However it is not visio, they are drawn on the fly using gd/GD.pm. 
The maps are png based with all objects (lines, rtrs, switches) as hot 
links back to the cgi which calls 14all. There is also submap definition 
and navigation. Also the lines are color coded by either speed, exported 
utilization values, or exported response values (on the fly when requesting 
the page). Very slick.

This environment for troubleshooting and analysis is nothing short of 
*superb* imho (daddy is proud of his kids along with mrtg/14all). However 
it took a great deal of effort and much time. But hey......you asked ;-).

Someday I'd like to offer this to the public and try this stuff out if they 
wish. I've made some strides towards that end, however at this time I'm not 
there yet. Hmm, maybe I should more formally describe the scripts in a doc 
for folks to look at. For those who may be interested in such a doc 
describing this environment in more detail (and its limits) drop me an 
email. If there is significant interest I will do this and get it onto the 
net somewhere.

cheers,
brad...

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi