# [rrd-users] Re: Manipulating and Graphing Data

Tarus Balog tarus at opennms.org
Wed Nov 1 00:12:57 MET 2006

```Tony Varriale wrote:

> Why I think it's wrong?  Well...0,1,3,0 isn't even close to the actual
> "total drops" which is my goal.  When set to GAUGE, it is close and I would
> be happy with that as long as I could take the difference between the
> current value and the previous and graph the difference.

Okay, maybe I can help here with an example from OpenNMS.

The value you are trying to graph is a counter. This is a value that
increases over time yet one is interested in the delta or change between
two values and not the actual value at any given time.

RRDtool handles counters quite well.

Now, as Alex mentioned, everything in RRDtool is a rate. You want to
measure "total drops". That is not a rate. Hence, it can not stored
directly via RRDtool.

However, if you have "drops per second" and "total seconds" it *is*
possible to calculate "total drops" by multiplying the numbers together.

For example. With OpenNMS we collect the counter ifInOctets (the number
of bytes inbound on a network interface). By default we do this every
300 seconds and we store that value in an RRA with a step of 300
seconds. We store the average value but since we are only storing one
value per step it will be the value collected (subject to the NOTE below).

So just suppose that I get the value of the counter and it is 100, and
300 seconds later I get the counter and it is 400, for a difference of
300. When I go to store that value in RRDtool it will be stored as a 1
(since 300 octets/300 seconds is 1 octet/sec). It *must* be stored as a
rate because that's what RRDtool does.

Now we have users who want a number that shows how many bits went by in
a certain time period. First a calculate the rate in terms of bits:

CDEF:bitsIn=octIn,8,*

Then in order to calculate the total number of bits I have to multiply
that value by the timespan of the graph:

CDEF:inSum=bitsIn,{diffTime},*

The {diffTime} is something that OpenNMS will pass to RRDtool and it
represents the end time minus the start time for the graph in seconds. I
then print out that value:

GPRINT:inSum:AVERAGE:"  Tot In  \\: %8.2lf %s"

Now, in your case you will need to find a way to come up with your own
{diffTime}. There are a number of ways to do this and you will probably
end up using something outside of RRDtool unless all of your graphs have
a fixed time range.

NOTE: As I mentioned above, if you try to store one value per step that
value should be the actual value collected. However, in practice that is
much harder than it seems to do perfectly all of the time. In any
automated system there will be some "drift" as the time to collect and
write the data can not be a perfect 300 seconds all of the time. Then
you may find yourself writing two values into one step and they will be
consolidated. However, your requirement was for a number that is "close"
and not perfect so you may be able to do this.

HTH,
-T

--

Tarus Balog
The OpenNMS Group, Inc.
Main  : +1 919 533 0160   Fax:   +1 503-961-7746
Direct: +1 919 647 4749   Skype: tarusb
Key Fingerprint: 8945 8521 9771 FEC9 5481  512B FECA 11D2 FD82 B45C

--
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://lists.ee.ethz.ch/rrd-users