[rrd-developers] problems graphing past end of RRD
Thorsten von Eicken
tve at voneicken.com
Mon Feb 25 16:05:06 CET 2008
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
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
> 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
>> 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!
More information about the rrd-developers