[mrtg] custom configuration decisions of which interfaces to monitor

Gene Titus gene at ots.utsystem.edu
Thu Aug 5 21:06:13 CEST 2010


I have my own code for deciding which interfaces to monitor with mrtg. I
keep the information about devices and interfaces in a mysql database and
build my mrtg configs and rrd files from the mysql database. Besides
traffic, I also monitor errors, discards, ucast, and nucast counters for
devices/interfaces that have them.

I've been making decisions on what to monitor based on the type of network
device ( cisco switch, IOS, CATos, Juniper swicth, Juniper router, Luminious
device, DWDM.........) and the description of the interface (ge, T1, vlan,
unrouted vlan...yada yada...). I have to take into account which version of
the OS is running on some network devices because some versions have certain
counters and some don't.

As with most projects that grow organically....over time, as we've added new
devices, the decision code getting rather unmanageable.

-Time for a new approach -

I'm going to move to a new scheme where I snmp query every interface
(ifindex) on the network device  to see if it has 32 or 64 traffic counters,
if it has errors, discards, ucast, nucast. That way I can do away with
worrying about the type of device and which version of the os it's running.
If an snmp query says it has the counter, monitor it. If not, then don't.
Sounds simple enough. (.... maybe to simple?....)

Does anyone see any problems with this approach? Is it going to come back
and bite me down the road (like my current approach has)?

p.s. I have code that runs every night to compare the mysql data against the
actual network devices to let me know if anything has changed. Our router
jockeys like to work in the middle of the night and change stuff and not
tell me.

Any advice or experience appreciated.

Regards,
Gene


-- 
Gene Titus
Sr Operating System Specialist
The Office of Telecommunication Services
The University of Texas at Austin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/mrtg/attachments/20100805/f05f911a/attachment.htm 


More information about the mrtg mailing list