Re: [rrd-users] Second opinion ...

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.

_______________________________________________
rrd-users mailing list
rrd-users@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users