Status / Monitoring - Last Sample Zero II

[NOYB]

Monitoring graphs last sample being zero

If there is no RRD data sample for the current minute then the graph, and last and minimum data values will be zero, and average skewed, in certain circumstances. Such as resolution 1 minute and graph loaded prior to the current minute RRD sample being made. Similar for the first minute of other resolutions and custom time periods.

This commit corrects this by restricting the 'end' option to no later than the RRD last sample time.

[jdillard]

What do you mean by "Similar for the first minute of other resolutions" and does a93f57d fix that?

I'll take a look at the custom time period parts tomorrow, that makes sense to me.

[NOYB]

For instance custom time periods are on hour boundaries. The first minute of each hour results in a zero value.

a93f57d for sure does not fix it for custom time periods. Don't recall now but maybe that was applicable to custom time periods.

P.S. shouldn't this "60" => "-2min" be "-1min"?

Also, don't have my old code in place to test with, but think only '-1min' was necessary to cover all resolutions. Think it just needs to make sure the end time reference is not beyond the last sample time and RRD workings takes care of it from there.

[jdillard]

Ah ok, I thought you meant for the preset time periods as well, makes more sense.

That commit was only intended to fix the preset time periods. I set it to 2min because it was hit or miss on a trailing zero value with only 1min. You set yours to 1min, but combined with the hack I removed (that chopped off the last sample value) it equated to two minutes (2 sample points).

[jdillard]

P.S. for the top part of your commit that gets the LST you can use the code at line 149 to line 151 instead:

$rrd_info_array = rrd_info($rrd_location . $left . ".rrd");
$left_last_updated = $rrd_info_array['last_update'];

and that code doesn't' have to stay there, probably more useful up top.

[jdillard]

I was working on this last night and got a little carried away. aaf5e5c has what I did for the top part and 20bde27 has the logic. does that fix look good?

rrd_fetch still adjusts itself for a best fit and can end up with weird start/end times, but it is a step closer and cleaner.

[NOYB]

Time period is 1 resolution too long.
Using larger (later) of left/right updated, instead of smaller (earlier), can result in zero ending value of the other.

Works but think this works better: 3d5e745

[jdillard]

Time period is 1 resolution too long.

Yup, you're right. I had -2min, because when I did -1min last time I was testing it would occasionally have a last zero value, but it must have been caused by something else.

Using larger (later) of left/right updated, instead of smaller (earlier), can result in zero ending value of the other.

makes sense.

[NOYB]

rrdtool fetch sometimes does return 1 or sometimes 2 nan responses. Can reproduce with a command line.
rrdtool fetch /var/db/rrd/WAN_DHCP-quality.rrd AVERAGE -r 60 -s end-1h

By using the last updated minus resolution, the nan responses are avoided.
Then also adjust start by adding resolution to retain the correct time period duration.

The 1 vs. 2 nan responses may have something to do with the relationship between time of the last sample data point relative to the last update time.

[jdillard]

I haven't forgotten about these @NOYB, just been busy. I should be able to get back to working on Status > Monitoring soon.

[gonzopancho]

ping @jdillard let's get to some resolution on this.