[rrd-users] One-off and no-data-problem

[Simon Hobson]

Jonatan Magnusson wrote:

>  >> 3. Why was not the updated value accepted?
>>  The interval starting at 3000000300 and ending at 3000000600 is partially
>>  defined, rate 123 between 3000000300 and 3000000400. There is no further
>>  update, so the PDP is not yet created, and therefore there also is no CDP
>>  yet.
>
>Now, this I just can't get my head around. I've read your tutorials and
>I think I understand most of it, but I'm still not sure just what is
>required to put a value in the database.
>
>I've replaced the update-command with one at 3000000599 and one at
>3000000601 and now I get this output:
>
>      3000000300: -nan
>      3000000600: 1,2300000000e+02
>      3000000900: -nan
>      3000001200: -nan
>
>But why is it necessary to supply two values for a gauge data point? And
>how long before or after must the values be supplied?
>
>If I declare a database to have gauge datapoints with a step of 5
>minutes, I would expect it to be enough to supply one value for each
>5-minute interval ... ?
>
>Or should I understand it like this: if I only supply one value, RRDtool
>does not know for how far in the future or past this value is valid. If
>I supply another value within the heartbeat time in the future, the
>first value is valid between those? And the value must be valid at the
>time boundary, so it is not enough to have a valid value *within* the
>step? Or maybe I'm way off .... :)

When you supply a value, it ALWAYS refers to the time leading up to 
it - RRD never deals with the future.

If you keep supplying updates which are not more than heartbeat 
apart, then each update will specify the value for the interval since 
the previous update to the current one.

As for gauge values, you need to remember that RRD tools do NOT store 
them ! RRD only deals with rates, when you specify gauge then you are 
bypassing the conversion from counter values to rates - but it's 
still assumed to be a rate.
Think of it like this, if you were logging distance/time/speed for a 
car then you could do it two ways :
1) Periodically tell RRD the odometer reading - it then knows how far 
you've driven and can work out the speed as (d1 - d2)/t. This is the 
COUNTER data type.
2) Periodically you can tell it how fast you are going by reading the 
speedometer. If you think about it, this is less accurate - you might 
have temporarily slowed down just when a reading is taken = but RRD 
will simply assume that you were doing the stated speed for the whole 
of the previous update interval. This is the GAUGE data type.

On update frequency. You can update as often as you like as long as 
you don't try and update more often than once per second. The most 
accurate in terms of getting out what you put in is if you update at 
the end of every step, and exactly on the step boundary. If you do 
this then normalisation becomes a null operation and you'll get out 
what you put in (given the limits of floating point storage).

If your updates aren't exactly on the step boundaries then 
normalisation will be done - did you read Alex's tutorial ?

Note that step boundaries are always an integer multiple of the step 
size from Unix epoch (midnight, 1st Jan 1970).


If you leave a gap longer than heartbeat between updates then the 
data for that period of time is specifically unknown.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.