[rrd-users] rrd fetch changes between 1.0 and 1.2

Alex van den Bogaerdt alex at ergens.op.het.net
Fri Feb 2 16:53:32 CET 2007

On Fri, Feb 02, 2007 at 03:44:51PM +0100, Gergely Madarasz wrote:

> Thanks, it's clear now. Btw this bug breaks munin's definition of 'total'.
> Munin adds together different defs, converting unknowns to zeroes, like this:
> CDEF:gpostotal=gdev8_0_write,UN,0,gdev8_0_write,IF,gdev8_1_write,UN,0,gdev8_1_write,IF,+
> not to have undef totals because of missing data.

Sure.  Adding anything to unknown results in unknown.

> Additionally munin sets the --end time to be on the exact boundary, but
> still gets an additional data row coming from future, which is undefined,
> gets converted to 0 in the total CDEF, so gpostotal:LAST becomes 0.

Try hacking the code, setting end time to boundary-1.  Maybe even try
starttime+1 as well.  This in itself may produce unexpected results if
other resolution RRAs are available, so be careful.

> This also breaks the current values of all virtual graphs defined in
> munin.conf by .sum. 
> I guess the correct solution for rrd_fetch would be that no data is
> supplied from the next interval if the endtime specified is exactly on the
> boundary of the previous interval. 

In that other thread I outlined what I believe to be correct.  Here's
another go:

Start time: if "on a boundary", do not touch.  Else, expand the time range
(decrease starttime) until it does fall on a boundary.

End time: if "on a boundary", do not touch.  Else, expand the time range
(increase endtime) until it does fall on a boundary.

Reasoning: the user wants to know about a certain time range.  RRDtool
has to try hard to include this time range.  Moving start or end time
the other way will present less data than requested, eventhough this
data is probably available.

User knows best.  If the user asks for a time that is not a whole
multiple of {stepsize * steps}, he probably has a good reason for it.

User knows best.  If the user asks for time "n-300 to n", do not provide
data for "n-300 to n+300" (if "n" is a boundary).

Alex van den Bogaerdt

More information about the rrd-users mailing list