[rrd-developers] problems graphing past end of RRD

[Thorsten von Eicken]

Alex van den Bogaerdt wrote:
> On Sun, Feb 24, 2008 at 04:52:31PM -0800, Thorsten von Eicken wrote:
> 
>> I'm having trouble when generating graphs that end after the last update
>> time of an RRD. The problem is that I sometimes get a much coarser RRA
>> than I should. The issue is that in rrd_fetch_fn there is code to
> 
> s/should/want/

Sure :-). But this becomes an academic difference when you're looking at 
a 600 pixel wide graph that shows a big staircase with a total of 22 
data points because supposedly this covers 20 more seconds at the end 
which you can't actually see.

>> Now suppose the requested start time can be covered by the second (140
>> second) RRA, you'd expect that to be chosen, but because the last point
>> of the RRA @4520s step happens to be 20 seconds later you get that one
>> instead!
> 
> More data, better match to what you ask (not want).

Define "more data". Getting 599 data points (last data point missing) is 
more data in my book than getting 22 data points that happen to cover 
the last 20 seconds.

>> The net result is that depending on how the end times of the various
>> RRAs line up you get a plot for the last day (that's what the 140 second
>> step RRA is used in my case) that uses the 4520 second step RRA which is
>> designed for the one month view! Not nice at all.
> 
> Then ask for an end time which is a whole multiple of 140, and not later
> than last update time. If your match can be exactly matched, it will.
> If there are multiple choices left, rrdtool will select the best resolution.

Actually, this doesn't work for a graph. Suppose the RRD updates are 
lagging behind by a few minutes. You have to show a graph that ends 
"now" (+/- some small margin). Even if I round the end time to a 
multiple of 140 seconds, the calculation will say that the coarser RRA's 
last data point is > the finer RRA's. The only way to get the finer RRA 
is to end the graph at or before the last updated data point in the RRA. 
This is definitely not what I want when showing a graph (and my users 
don't either).

>> I suggest removing the partial-match adjustment based on the end time,
>> but maybe I'm missing a use-case where this is important.
> 
> Maybe. Changing this could mean a change of expected behaviour for
> a lot of other people.

Dunno. I have to admit that some of the "expected behavior" of RRDtool 
is pretty lousy. I have been using it since it first came out and I'm 
very grateful for it, don't get me wrong. Here's an example. If I ask 
for a 600 pixel graph at 150 seconds per pixel with the above RRAs, the 
140 second resolution RRA gets whacked into a 280 seconds per data point 
array and then the 150 seconds per pixel graph gets interpolated from 
that, resulting in 2 pixel-wide stair steps. My "expected behavior" 
would have been for rrd_graph to interpolate the 600 data points 
directly from the 140 second RRA resulting in a graph with about 2x the 
data displayed. Unlike for the end-time issue I don't have an easy fix I 
can submit, so I wasn't going to mention the problem...

Cheers & thanks for all the work that is going into RRDtool!

Thorsten