[rrd-users] [unsure] Adding updates but fetch shows NaNs

[Issaac B]

Thanks, Alex! The last but about the double update did it for me.
I split my Python script into two objects which each did their own
rrdupdate and set half the values to U.
By combining the data into a single update, my values are now working just
fine.
I thought that the U would be the same as no-update but apparently not.

On Mon, Jan 22, 2018 at 11:18 PM, Alex van den Bogaerdt <
alex at vandenbogaerdt.nl> wrote:

> > I was hoping someone could help me understand how values are computed in
> > RRD.
> > I got a temp database (create below). I got a loop that adds an update
> > ever
> > ~2 minutes.
>
> 120 seconds.
>
> And your interval (database step) is 200 seconds.
>
> > rrdtool info says the DS got known values for the last two
> > columns (ext_temperature, ext_humidity).
>
> and also reports part of the interval is unknown.
>
> Guessing here, I did not do all the exercises: my guess is that you always
> have part of an interval set to unknown data.
>
> Suggestion to debug, and maybe also to make permanent changes to your
> database setup:
>
> 1: set your database to step==1
> 2: the RRAs you already have, collect data 200x the current step size
> (e.g. you now have RRA:AVERAGE:0.5:1:2016 this becomes
> RRA:AVERAGE:0.5:200:2016 )
> 3: an extra RRA expects data every 1 step. It won't get it that often, but
> that does not matter. Just make sure heartbeat is set high enough.
> 4: also keep MIN and MAX if so desired
>
> This new, extra RRA aids in debugging. Just make it long enough to look
> back an hour or so (3600 seconds). Longer if you wish to keep and use the
> data. Disk space is cheap.
>
> Your previous setup: one complete interval was 200 seconds and you needed
> at least 2 updates for it to fill. The new proposed setup completes more
> than one interval of 1 second each time you update.
>
> If you see weird rates in the first interval of such ranges (rates being
> pulled to zero), then your version of RRDtool suffers from the
> sub-second-precision bug. Ignore, or make sure you update with integer
> timestamps instead of "N" for now.
>
>
> Last but not least:  if you receive your data as one batch of numbers,
> then never mind but if you receive your numbers separate from each other,
> then do not combine them in one RRD database.
>
> E.g. update x:1:2:3:4:5:6:U:U followed by update x+1:U:U:U:U:U:U:1:2
> messes things up. It will NOT result in only updating the first 6 DSes and
> then only the last 2.
>
> HTH
> Alex
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.oetiker.ch/pipermail/rrd-users/attachments/20180123/74df2715/attachment.html>