[rrd-users] Second opinion ...

[Simon Hobson]

Marc T. Kaplan wrote:

>Yes, this was a typo and I did mean 86400, I have gone through and
>tested this script a bit more but still see values being returned of
>"UNKN." When you stated to set the sample period as 600 to accelerate
>the day you are referring to the DS heartbeat or the RRD heartbeat?

I'm suggesting that everywhere you are using 'one day', you use 
something shorter (for example 10 minutes) so that you can experiment 
and see results that much quicker. You'll have to re-create (for 
testing) your rrd database with a step size of 600 instead of 86400 - 
but you'd be building a fresh one anyway between testing and going 
live (I would anyway).

>With the "N" time stamp for updates, what other methods would you
>consider using to update the RRD?

The issue is whether you want to avoid or minimise normalisation.

If you use N then the time is whatever time the update call is 
actually made - which may be several seconds after the samples were 
read if it's a complex script. So rrdtool would add 86397/86400 of 
your sample to the last period, and 3/86400 of it to the next 
(assuming 1day steps and an update 3 seconds after midnight). That 
may or may not matter to you - but there's a regular query appears on 
this list of "I put in X but got out Y" due to this.

One approach is to use this pseudo-code :

T=time_now
U= T - ( T mod $step )
<stuff to get sample data>
rrdtool update U:.....

The same applies when graphing data, you should make your start and 
end times an integer multiple of the step size for the RR you want to 
use.