I noticed the graph for robin.davehart.net had the offset Y axis blown out by a 765ms offset reported by a monitor after a restart, when ntpd had not yet synced and was properly reporting as much with leap=011 (3). It seems to me that either the monitor should log a zero offset when leap is 3, and/or the graph should ignore such log entries:
Not sure how servers populate time-related fields in responses when they are unsynchronized, whether offset derived from them might make some sense in some circumstances so it would be worthwhile recording. But for practical reasons, the graphing system should ignore offset values in these cases on its end, whatever they are:
While the handling of RATE KoDs has been updated a few days back already, zeroing the offset value in log entries corresponding to such KoDs, not all monitors seem to have been updated yet, continuing to report bogus offset values, which in turn blow up the graphs:
Though I understand from a separate thread that changing the JavaScript-based graphing system might be more challenging than changing the monitor implementation…
Hmm. The graph JS already does a little .filter() to separate scores into two categories (whether monitor_id is null). I suppose the backend can add a new key called error and have the JS separate on whether the key is present. At the very least, it can choose to not send an offset.
From the monitoring data on my server, it looks like the backend already sends data points without an offset and only a score, so the “at the very least” part is feasible. Interestingly though, I’m not seeing any data point where monitor_id is null – I wonder why the code to act differently is there.
Drawing an indication where the errors occured is possible, but that… will take more work. The circle-translate(...) code will be working with other shapes, like uhh… verticale bars? instead.
