[rrd-users] Still having problems

[Sam Umbach]

> So you feed in the number 7 after a one day interval. The program
> computes the rate as 7 / 86400 <somethings>/second and stores that -
> assuming you update on a step boundary.
>
> If your updates are not exactly on the step boundaries then the
> program will normalise what you feed it to fit. For example, if you
> do updates at half-time (ie 12 noon), then each stored sample will be
> 50% from one update, and 50% from the next. If you update at 6am,
> then stored samples would be 75% from one update, 25% from the next.
>
> In your case I think it's simply a matter of scaling. You can either
> multiply what you feed in by 86400, or you can multiply what comes
> out by 86400 when you come to graph it.

I recommend against scaling the value in this way.  The GAUGE data
source type is exactly what you are looking for here.  With GAUGE
(instead of ABSOLUTE) the data provided to rrdtool update is treated
as a rate (units are 1/s) and it is stored in the database as is
(without being divided by the time period).

Note: if the updates are not made on 24-hour boundaries (12 midnight
UTC), then Simon's comments about normalization still apply.

The important thing to realize about rrdtool is it is meant for data
__consolidation__; it is intended for archival of trend data.  The
most typical use is when you need different resolutions for different
time periods (every 5 minutes for the past two days, every 30 minutes
for 30 days, every 6 hours for 1 year, etc).  If you need to store a
tuple (time + data value) and retrieve exactly that tuple at a later
time, rrdtool is NOT for you.  rrdtool is not inaccurate, but it does
consolidate data, so you generally cannot retrieve the exact value you
inserted.

-Sam