Cheshire Cat Computing

Steve,

I've been using routers2 for about 2 months to monitor Cisco devices, more than 30. Let me tell you that I love it !!! Eveything was fine until last week, when I relaized a very weird problem, not sure if it is routers2 or mrtg related, or anything else. I relaized that traffic charts are not continuous but broken.

I schedule mrtg in cron to run every 10 minutes pulling traffic information from all devices so I guess timing is good. Now I see that charts are rising up from 0 to the real traffic value, staying on the top for bit, then immediately going down to zero. Therefore my charts (all) looks like sawtooth wave. It's not continuous but broken, dashed... which is not really "readable" and aesthetical. I did not touch my server config, it just turned into a nightmare...

originally I used the 2.16 version of routers2, I upgraded to 2.17, but issue is same, of course I use growright, bits, unknaszero options. I use Redhat AS, processor utliziation is very low even if mrtg is running. There are NO processes slowing down the system, or got stucked, so everyhing is ok from the OS side...

suggesstions are really appreciated !

thank ya,
planar
[/img]

_________________
planar

Your problem is that you schedule MRTG to run every 10 minutes.

The 'normal' polling cycle for MRTG is every *5* minutes, and as this is the default routers2 makes a few assumptions based on it, although it reevalutaes these based on the .rrd file configuration. Your .rrd files probably have 5-min intervals, with every other sample set to 'unknown'.

Possibly, you initially created the .rrd files with an implicit 5-min interval, but collected the data later on a 10-min cycle? This can cause problems if your xff setting is too low (looks like you're OK as you have 50% of expected data) and messes up some calculations at Daily level.

I would suggest either polling at 5-min intervals, or use 'rrdtool dump' to check the interval size in the .rrd files and delete and recreate the ones with a 5-min interval. This is awkward and of course loses your historical data.

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

_________________
planar

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

_________________
--
Garry Cook

The world is a dangerous place, not because of those who do evil, but because of those who look on and do nothing.
~Albert Einstein

About 4500 metrics a cycle?

What disk backend do you use - I've found everything bottlenecks on disk IO here. SAN would be quicker, but I dont want to lose monitoring if the SAN is out. I guess I should just add more spindles to the SCSI array...

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

Hehe, yes, I guess I should have added the fact that this (and all my other monitoring apps, Nagios, NeDi, Smokeping, etc.) run on Ubuntu virtual machines (VMware ESX) on blade servers with SAN storage.

_________________
--
Garry Cook

The world is a dangerous place, not because of those who do evil, but because of those who look on and do nothing.
~Albert Einstein