[rrd-users] Re: Need help understanding consolidation

On Thu, Oct 19, 2006 at 10:01:04AM -0400, Jeremy Hough wrote:

> If I update only ifHCInOctets, or only greenBytes and redBytes, the results
> are what I expect. However, if I update all three, I get all NaNs. I
> expected with the xff set to 0.99 that 1 known data point and 1 unknown data
> point during the step would consolidate into a known data point.

But it doesn't. And that is to be expected.

> Interestingly, if I substitute COUNTER with GAUGE, I get values, so I
> presume it is a nuance of consolidation with respect to the rate
> calculation.

This is a wrong assumption.

In all cases, rrdtool computes a rate. This rate is then normalized and
consolidated in the RRA's. There is no difference whatsoever between rates
coming from COUNTER and rates coming from GAUGE.

You are correct in thinking that rate calculation has something to do
with your problem, but consolidation is unrelated.



How does rrdtool compute a rate?

GAUGE: do nothing. The number is a rate. Use it.

COUNTER: take the previous counter value and time. Compute
differences, divide delta(counter) by delta(time). This is the rate to use.


If I may abbreviate your counters to a,b and c:

1: you update a only
2: you update b and c
3: you update a only
4: you update b and c

and so on.

If you don't tell rrdtool what a counter value is, it is unknown. Thus:

1: you update a only; b and c are unknown
2: you update b and c; a is unknown
3: you update a only; b and c are unknown
4: you update b and c; a is unknown
5: you update a only; b and c are unknown
6: you update b and c; a is unknown

and so on.

In step 5, you update a.
rrdtool computes: (value_a_step5 - value_a_step4 ) / (time_step5 - time_step4)
which is: (value_a_step5 - unknown) / (whatever)
which is: unknown by definition

And this is true not only for "a" and step 5. It is true for all other
steps and DSes.

Using GAUGE means "step_4" does not influence "step_5".



Possible workaround:
Create two databases, one for "a", one for "b,c". Update them as usual.
Every now and then (for instance: each hour), read normalized rates from
these two databases and use them to update a third database. This 3rd
RRD then uses GAUGE (as you are inputing rates) so you won't have your
problem. As an added bonus, you will not see so many unknowns.

HTH
--
Alex van den Bogaerdt
http://www.vandenbogaerdt.nl/rrdtool/

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