[rrd-users] Re: is this my fault?

Warnes, Jason SktnHR jason.warnes at saskatoonhealthregion.ca
Thu Feb 6 06:16:35 MET 2003


Might I suggest trying this,

First check for the existance of the RRD file when your script runs, if it
doesn't exist then assume you're creating a new file and either:
	a) set the previous values to the current values instead of looking
them up in your RRD,
Or
	b) when you create your RRD set input a value of the current value
for what would have been the previous poll period. So your RRD would have a
starttime of [current time]-[poll period] instead of [current time].

So in each case your delta's are 0.

Might work...

Jason...

-----Original Message-----
From: Adam Glass [mailto:rrdtool at adam.clarity.net] 
Sent: February 5, 2003 7:48 PM
To: rrd-users at list.ee.ethz.ch
Subject: [rrd-users] is this my fault?



I'm seeing some strange behavior from rrdtool that I think the program ought
to handle, but which might actually just be my fault.  You guys can be the
judge...

I wrote a program to retrieve byte counters from firewall rulesets and graph
them by protocol.  The byte counts are COUNTERs, as they are neither reset
upon reads nor a value covering the previous x minutes.

The firewalls have been running for a while, so the byte counts for each
firewall rule are fairly large.  What seems to be happening, however, is
that the first update is compared against zero, meaning that the delta for
the first time period is astronomical.  The deltas between successive
datapoints are normal.  Here's a hypothetical example of what seems to be
happening:

  first read:  byte count is 1000000  delta from last: 1000000
  second read: byte count is 1000050  delta from last: 50
  third read:  byte count is 1000200  delta from last: 150
  etc

This makes auto-scaled graphs all but unreadable until the first
astronomically huge value has disappeared from the time window being
graphed.

Here's an example of a graph where the data has scrolled out of view, and
where things look the way they should:
  http://www.clarity.net/adam/images/temp/daily.png

Here's an example of a graph where this initial huge value is making it
impossible to see the subsequent nominal data:
  http://www.clarity.net/adam/images/temp/weekly.png

And lest you think that there's no data being graphed, here's a protocol
that generated enough data in subsequent time periods to actually have some
data appear:  (Look closely.)
  http://www.clarity.net/adam/images/temp/weekly-http.png

So, is this my fault?  Shouldn't rrdtool realize that it doesn't have any
previous data, and not calculate the rate of change by comparing the initial
data to zero?

There are a couple of things that I could do to prevent this, all of which
are fraught with unpleasant consequences:
  - set a maximum value when creating the DS
  - set a fixed (and small) range of values in the Y axis
  - use a CDEF to limit the values when graphing
  - write a wrapper script to calculate the rates of change and
    only output a non-zero rate of change when it has a valid
    previous value against which to calculate a delta
  - reset the firewall rule byte counts when creating the database
  - be patient and wait for the large values to leave the
    graphing window  :)

None of those are good options.  Am I doing something wrong?

Adam

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

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