[rrd-developers] problems graphing past end of RRD

[Alex van den Bogaerdt]

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/

> determine the best partial match which kicks in when plotting past the
> end of the RRAs and if the step times of the RRAs aren't multiples of
> one-another strange things happen.
> 
> The code calculates the matched time portion as follows (approx line 276
> of rrd_fetch.c):
>      /* best partial match */
>      tmp_match = full_match;
>      if (cal_start > *start)
>          tmp_match -= (cal_start - *start);
>      if (cal_end < *end)
>          tmp_match -= (*end - cal_end);
> I don't understand the purpose of calculating the end-time coverage. As
> far as I know, all RRAs end at the same time, modulo their respective
> step sizes. So they all cover up to the last update moment (again,
> modulo step size) and we should really exclusively focus on the start
> time coverage.

A partial match covers the largest possible time range, not the
best possible resolution.

> Here is the abnormal situation I run into. I have RRAs with step sizes
> (in seconds): 20, 140, 1020, 4520, 13440, 53360. Suppose I need to plot
> a graph ending at 1203888560 when the last update time was 1203888537.
> The last points stored in the first 4 RRAs are:
>    20: 1203888537 - 1203888537 % 20 = 1203888520
>   140: 1203888537 - 1203888537 % 140 = 1203888420
> 1020: 1203888537 - 1203888537 % 1020 = 1203887640
> 4520: 1203888537 - 1203888537 % 4520 = 1203888440

Note how 1203888560 is larger than 1203888537. You can expect that
rrdtool will not be able to exactly match your request, so you should
expect the partial best match to kick in.

> 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).

> 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.

> 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.

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