[mrtg] custom configuration decisions of which interfaces to monitor

[Daniel McDonald]

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. 

Sounds good.
> 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
version.

> 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
> me. 
> 
> Any advice or experience appreciated.
> 
> Regards,
> Gene
>