[rrd-users] can't sanity-check rrdtool with sample data ... please help

[Simon Hobson]

Gore Jarold wrote:

>So this is the other problem - and I'll just make the
>question easy:
>
>If my update command is:
>
>rrdtool update hits.rrd 1141286400:1 1141372800:10
>1141459200:10 1141545600:12 1141632000:12
>1141718400:12
>
>and I want my output with fetch to give me:
>
>1,10,10,12,12,12
>
>Then what is wrong with my 'rrdtool create' statement:

Nothing, it's your update statements that are wrong.

>rrdtool create hits.rrd --start 1141200000 --step
>86400 DS:hits:GAUGE:172800:0:U RRA:MAX:0.5:1:3650
>
>because right now, instead of the 1,10,10,12,12,12
>that I put in, I am getting:
>
>1141257600: 1.0000000000e+00
>1141344000: 7.0000000000e+00
>1141430400: 1.0000000000e+01
>1141516800: 1.1333333333e+01
>1141603200: 1.2000000000e+01
>1141689600: 1.2000000000e+01
>
>when I fetch it back out ... (1,7,10,11.3,12,12)

Notice that the timestamps are different - there's 8 hours difference 
between the boundaries of the stored step intervals and the points 
you feed in data for. 
http://www.vandenbogaerdt.nl/rrdtool/process.php explains the 
normalisation that goes on, but in this case it means that for every 
value you feed in, 1/3 goes into one bin, the other 2/3 goes into a 
different bin.

See what goes into the different bins
1/3 of unknown, plus 2/3 of 1 over 2/3 of the time = a rate of 1
1/3 of 1 plus 2/3 of 10 = 7
1/3 of 10 plus 2/3 of 10 = 10
1/3 of 10 plus 2/3 of 12 = 3.3 + 8 = 11.3
1/3 of 12 plus 2/3 of 12 = 12

It would help you visualise this if you plot the points of the 
updates and the boundaries of the 'bins' on the time axis as is shown 
on the web page above.

Fundamentally the problem is that you are thinking of an RRD like a 
traditional database where what you get out is what you put in - it 
isn't. RRD is designed to normalise data to fit specific timeslots so 
in the general case what you get out is a normalised (and usually 
consolidated) version of what went in.


This isn't the first time this time issue has come up, the tools 
don't support 'daily' samples over anything other midnight-midnight 
UTC which is not always what people in other timezones want. However, 
I suspect that modifying the software to support a 'zero point' 
offset from unix epoch/UTC would be non-trivial.