[rrd-users] Re: Manipulating and Graphing Data

Simon Hobson linux at thehobsons.co.uk
Tue Oct 31 21:31:06 MET 2006


Tony Varriale wrote:

>Ok...well...DERIVE doesn't give me accurate numbers.  Not even close.  That
>is why I am trying to ask the community for a solution to the problem.

OK, try giving us an example of :
what you put in
what you expect to come out
what you actually get out
and if the latter two are different, why you think it's wrong !

because from what you've written so far, I believe derive would be appropriate.

>  > GAUGE is _not_ a value, it is a rate.  And it is subject to
>>  any normalization and consolidation like any other rate.
>
>Well...I'm really confused.  Here is what it's states from the beginner's
>guide:
>
>"GAUGE does not save the rate of change. It saves the actual value itself. "
>  Values       = 300, 600, 900, 1200
>  Step         = 300 seconds
>  COUNTER DS   =    1,  1,   1,    1
>  DERIVE DS    =    1,  1,   1,    1
>  ABSOLUTE DS  =    1,  2,   3,    4
>  GAUGE DS     = 300, 600, 900, 1200Could you clarify this?

I think I see where your confusion comes from, that particular bit of 
text is slightly misleading - not wrong, but incomplete. I think the 
problem is that you have to try and explain the fundamentals without 
getting in too deep to start with. The statement is correct IF, and 
only if, the updates are supplied (or more correctly timestamped) 
EXACTLY on multiple of the rra step period - if the samples are given 
at any other time then they get apportioned accordingly (someone 
please correct me if I've got that bit wrong !)

What it's trying to say is that with a guage value, what you feed in 
IS the rate, not successive values of something that the rate is 
derived from. Eg, if you have 1 <something> per second, over 300 
second periods you would get 300, 600, 900, etc and counter or derive 
would subtract the previous count to get 300 before dividing by the 
interval to get the rate of "1"; whereas with a guage type, you have 
(by whatever means) already got the rate of "1" and so feed that in 
where it is stored without having to convert to a rate first but 
processing the updates to apportion inputs to time intervals.

However, even if you manage to get the data in at the right time, a 
fundamental function of rrd is to apply consolidations to give you 
data over a longer period at a lower resolution - once these 
consolidations are applied, then the stored value will not be exactly 
what you put in.

--
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
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi



More information about the rrd-users mailing list