[mrtg] Re: MRTG to monitor Gigabit-ethernet with counter32 and interval: 1

[Alex van den Bogaerdt]

sigh.

Please do me a favour and stop:
1) top quoting
2) writing long lines

On Tue, May 27, 2003 at 02:09:02PM +0200, Michael Markstaller wrote:
> My RRD's were created with "Interval: 5" and they still have "step = 300" when I do "rrdtool info", but the mrtg-instance runs every 1 minute now so this should give me quite accurate values; this isn't used for any accounting or smth similar so some errors are ok. The traffic I expect isn't much higher than 200 MBit so it should work in this case for me. There's also a newer software-version of the 3Com 4900 available but in the release notes there's nothing about snmpv2... Easiest thing would be to get this customer buy a Cisco ;)

s/a cisco/any device capable of producing the stats/

> As we're talking about counter-warps ;) Another thing I already asked some time ago on the list, I still haven't completely understood on which criteria mrtg relies to detect a counter wrap. Because I have another problem, much more annoying (because this data IS used for accounting), that spikes are generated for most graphs when a device reloads. 


if cur_value < prev_value then assume cur_value is 2^32 too low

In your car/on your bike it is similar:

if cur_mileage is smaller than prev_mileage then assume cur_mileage
needs a 1 prepended.

999987  --> 1000002   increase = 1000002-999987 = 15

Same result:
999987  --> 000002  increase = 2-999987 = -999985
result is negative --> add 1000000 --> 15



> I wrote debugs now the last few weeks but had no time to analyze in detail so far; it seems that for some reason mrtg thinks the counter wrapped instead of counting from zero after the reload. I found an intersting post from you from Dec 2001 which exactly describes how it should be handled (with looking on the uptime of the device) but as far as I can see mrtg doesn't do this (??) 

Could be, many things have changed since I last looked.

> I found in mrtg on line 328:
> --- cut ---
>               if ($inlast < 0) {
>                 $inlast += 2**31;
>                 # this is likely to be a broken snmp counter ... lets compensate
> --- cut ---
> This looks for me like the part which creates my spikes, but should never get executed as I use rrdtool for all graphs ?? So is this "feature" creating my spikes probably in rrdtool self (using RRDtool 1.0.41) and I was looking on the wrong thing (mrtg) all the time.

This will result in spikes lower than the MaxBytes setting.  The lines
in MRTG are similar to what RRDtool does, RRDtool also covers the case
where 64-bit counters are used.

The wrong place usually means you have been looking at spikes whereas
you should have been looking at MaxBytes.  If you tell MRTG or RRDtool
that 2^31 is OK, you'll get it.  Perhaps the setting in the RRD isn't
done during the conversion, check with rrdtool tune.

HTH
Alex

--
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