[mrtg] custom configuration decisions of which interfaces to monitor
dan.mcdonald at austinenergy.com
Fri Aug 6 15:08:49 CEST 2010
On 8/5/10 2:06 PM, "Gene Titus" <gene at ots.utsystem.edu> wrote:
> 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.
I've been meaning to build something that deals with negative dB power or
loss gauges. I always have to go back and manually tune those RRDs. Have
you got code you can share that would deal with that?
Daniel J McDonald, CCIE # 2495, CISSP # 78281
> 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.
Yeah, I ran into that. I use templates for each device type, and check to
see what counters are available and build the config based on those
counters. Trying to track free/used memory on Cisco routers is the worst
because there are like 5 different mibs that are used depending on the
> 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.
Yes, sounds like the right approach.
> (.... 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)?
If you are polling a lot more points, just make certain that your poll time
is still reasonable. If you get above 3 minutes or so for polling, then
anything that goes bump can pitch you over 5 minutes and the whole system
will start failing with the overlapping polls.
> 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
> Any advice or experience appreciated.
More information about the mrtg