[rrd-users] LAST always returning zero

Alex van den Bogaerdt alex at ergens.op.het.net
Fri Mar 7 13:55:38 CET 2008


On Fri, Mar 07, 2008 at 12:59:43AM -0600, Wes wrote:

> Based on your explanation I've been playing with rrdtool fetch on the live
> data.  I see that it returns the next timestamp after the current time as
> all 'nan', plus possibly one additional line of nan's, depending on the last
> update time.  
> 
> For example, if the current time is *474, fetch returns:
> 
> *460: good data
> *470: nan nan nan...
> *480: nan nan nan...
> 
> Which explains why when I did "now-30", it works.  "now-20" usually works,
> but sometimes fails, apparently if there is a delay in update.  Because of
> this, "--end $(($(date +%s)/10*10))" only works some of the time.

Correct. In such a case you are behind with updating.

> Is there not a way to say:  --end lastSavedDataPointTime  ?  I can do the
> following, and it appears to work, but it seems rather high overhead:
> 
>     --end $(($(rrdtool last test.rrd)-10)

Correct, although I'd substitute /10*10 where you have -10. Your line
always removes the last row, even if that one isn't NaN.

> I have to do the -10 because "rrdtool last" appears to return the timestamp
> of the last second of the time period, not the first second of it.

RRDtool time intervals are defined by their end time and their duration,
thus (in your case) timestamp 1204894150 means 1204894140..1204894150.

You may want to try the development snapshot, just recently a change
was made in how RRDtool handles these kind of end times.

Previous behaviour: The user wanted to see time *474, so include 470..480.
Current behaviour: The user probably ment to ask for *460, so gamble that
he indeed did and modify the request.
(N.B. this is based on mailing list conversations; I haven't looked
at the release yet so details may differ)


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



More information about the rrd-users mailing list