Cheshire Cat Computing

I have tried both v2.14 and 2.15beta2 and both act the same way.

I have split up my MRTG configurations into multiple files.

Under one of the configurations, I'm monitoring my router's interfaces. Then I have one special MRTG directive to sum up all of these statistics so I can get an idea for total throughput through the router.

Under another configuration, I'm running a perl script against SpamAssassin to monitor it.

What is interesting is that some of the graphs seem to plot while others don't. The total throughput for my router and the SpamAssassin work. However, all other graphs are flat-lined. The Last field shows 0.00 and the Cur in the graph shows 0.00.

Now, I thought MRTG was somehow not functioning. Running from the command revealed nothing.

I installed mrtg-rrd.cgi and the plots for it are working just fine, so it seems to be in routers2.cgi. I have hunted for the lowdown on this and can't seem to find it. Anyone else have any ideas?

Okay now everything went to 0. However, I found that only the Summary view does this. If I do a compact summary, it shows data. Also if I click on a certain interface, it graphs fine, but the current in/out is 0.

This is an effect of the unknaszero option.

Sometimes, if your graph generation is sufficiently out of synch with the data collection, then the graph generation falls into the next sample window of the RRD. This means that it returns an 'unknown' for the last value (since no data has yet been collected for this window).

routers.cgi has a workaround for this, since it usually only affects the userdefined graphs, but if you have unknaszero then unknown is already set to 0 and so you get this effect. I'm not sure how mrtg-rrd avoids its -- I suspect it doesn't, but that you just asked it to generate the graphs in the same time window as the data collection and therefore avoided the issue. With touters.cgi, due to its caching and expiry, once you get out of the window it's hard to get back in again

I'll look more into finding a more reliable workaround for this -- maybe using the lastupdate time as the base if it is more recent than the update interval... (you can set 'uselastupdate = yes' in the routers2.conf to have this affect, also)

Steve

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