[rrd-users] One-off and no-data-problem
linux at thehobsons.co.uk
Thu Dec 30 18:23:31 CET 2010
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
>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.
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.
More information about the rrd-users