[rrd-users] Re: how does rrd ahndle router reloads ?

BAARDA, Don don.baarda at baesystems.com
Tue Feb 6 01:32:36 MET 2001


G'day,

> -----Original Message-----
> From:	Patrick Ammann [SMTP:Patrick.Ammann at nextra.ch]
> Sent:	Monday, February 05, 2001 9:33 PM
> To:	rrd-users at list.ee.ethz.ch
> Subject:	[rrd-users] how does rrd ahndle router reloads ?
> 
> Hi,
> 
> I just was wondering how RRD would handle router reloads. Currently i'm 
> monitoring some cisco routers (interfaces, memory etc.). The problem i had
> 
> is that from time to time i can see some peaks in my graphs and i couldn't
> 
> find a reason for this peaks. First i thought there were some warps of 
> counters but i was told that RRD can handle those warps. SO i looked
> closer 
> to the database and now i'm sure that the peaks occur every time a router 
> reloads. The peaks are really confusing me because the graph i attached is
> 
> from a physical 2 MBit line so there is no way to have a 50 MB peak on
> this 
> line.
> 
> Did anyone made the same experiences like i did ?
> 
	This has been discussed repeatedly on this list, so yes, heaps of
people have experienced this "problem". A quick peruse of the list archives
would reveal many answers to this question.

> I think that the problem could be solved when there were some min and max 
> values but the capacity of the leased lines is changing quite often and i 
> don't want to set all the min and max values each time. Is there another 
> way to get rid of this problem ?
> 
	The correct way to solve this problem is a reasonable max value.
Note that "reasonable" is a flexible term. You don't need to set max to
_exactly_ the max capacity at the time. If the capacity is changing, then a
reasonable max is the max capacity that it is likely to have over the life
of the RRD database. If your capacity does eventually exceed this max, then
you can adjust it when that happens, which is better than changing it each
time the capacity changes.

> Is it possible to let the RRD check if the actual value of octets is 
> smaller than the last one stored in the database and if so just put a NAN 
> in the database ? This would cause a missing value and also counter warps 
> won't be handelt with this change but in my case this doesn't occur very 
> often so i prefer loosing one data sample instead of makeing the hole
> graph 
> unusable.
> 
	A DERIVE DS is a COUNTER DS with wrap compensation turned off, which
will do what you are asking if you use min=0. However, this is a poor hack
solution compared to setting a reasonable max.

	When a COUNTER goes backwards, rrd assumes it has wrapped, and
calculates the rate accordingly. The only way to differentiate a counter
reset from a counter wrap is if the resulting rate is unreasonable. The only
way to determine if a rate is unreasonable is if there is a max and min rate
set. Note that typically, a reset results in rates that are huge compared to
normal rates, so even a max setting that is way above the real max capacity
will catch most resets.

	The average rate returned by a reset for a 32 bit counter will be
(2^31)/step + avg_rate/2, where avg_rate is the average true rate of the
interface. This means that rates for resets will on average be larger than
2^31/step (7MB/s or 57Mb/s for step=300), so even a max of 2^30/step
(3.5MB/s or 28Mb/s for step=300) will catch more than 75% of resets. For
64bit counters, this becomes (2^63)/step and (2^62)/step respectively...
which is _huge_. So even an unreasonable max will catch most counter resets,
and is a better solution than DERIVE with min=0...

> Is there a simple way to modify the RRD Source ? Anybody did it already or
> 
> does anyone have a better solution ?
	[...]

	You don't want to modify the source. It does what it should do,
which is actually what you want :-)

	ABO

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi



More information about the rrd-users mailing list