[mrtg] MRTG/spikes after router reboot with fix/patch for 2.9.29

Michael Markstaller mm at elabnet.de
Wed Nov 5 17:17:24 MET 2003


In short words, I made a fix to mrtg to prevent these nasty spikes by looking at the uptime with snmp.
The patched mrtg worked fine the last weeks without generating a single spike so I wanted to contribute it.
In longer words, some preface: 
I'm using mrtg 2.9.29 and rrdtool 1.0.41 and I still get crazy 
with spikes in my rrd-data after reloading hosts due to mrtg/rrdtool simply "guessing" a 
counter-wrap occured.

I think I fully understood what these spikes are caused by and that they can be lowered 
and sometimes avoided with using lower maxbytes values, mainly by an reply
from Alex van den Bogaerdt (thanks!): here http://www.ee.ethz.ch/~slist/mrtg/msg24228.html
but some spikes stay, at least for 100Mbit interfaces.

I asked for this some time ago, http://www.ee.ethz.ch/~slist/mrtg/msg23802.html
and after going through the code I know now why it is a problem to simply look at the uptime: 
it's returned as a nice human-readable string like "5 days, 4:12:22" instead of the raw timeticks.
this seems to be done by SNMP_util.pm for every snmpget using BER.pm - so far so bad, no reason to give up 
(yes, I'm really fed up getting spikes!)

What the patch does:
- prevent spikes by logging at least one unknown-value after a device reloaded
- getting an indication that something reloaded as grey bar (depends on frontend, more a side-effect of the above)

my goals were:
- doing the least possible changes to mrtg-source in case I have to transport this to future versions myself
- make it stable, fast 
- configurable and off by default (in case somebody still likes the spikes)

all hoping that this portion gets included into the main MRTG distribution, 
I know that 2.10 is already out but this was done before.

as anything else would've required either changes to SNMP_util or doing a separate poll, I decided to 
recreate the Uptime-timeticks from the friendly string as this seemed to easiest way with making least 
changes to source.. don't beat me for the sourcecode, I'm no perl guru.

In case anybody is concerned about the traffic-overhead caused by this, as I was, it's about 34 bytes per poll per target, 
so for a host with 28 tagets its 100MB per year (for additional polling of the uptime)

The whole thing as stated is disabled by default, a global config option:
"CheckUpTime: yes"
enables it.
I created a diff of mrtg itself and MRTG_lib.pm (needed for the global config option) as stated in contrib..

regards

Michael Markstaller

Elaborated Networks GmbH 
www.elabnet.de 

-- Attached file removed by Ecartis and put at URL below --
-- Type: application/octet-stream
-- Desc: mrtg-2.9.29-p1.diff
-- Size: 3k (3411 bytes)
-- URL : http://www.ee.ethz.ch/~slist/p/mrtg-2.9.29-p1.diff


-- Attached file removed by Ecartis and put at URL below --
-- Type: application/octet-stream
-- Desc: MRTG_lib.pm-2.9.29-p1.diif
-- Size: 727 bytes
-- URL : http://www.ee.ethz.ch/~slist/p/MRTG_lib.pm-2.9.29-p1.diif


--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi



More information about the mrtg mailing list