Improve ntpd helper script

[SuperQ]

From #423 (comment)

@SuperQ thanks for the hint. However, ntpq -pn gives you a view of the sync status per sources, it is useful information but not enough to know the "quality" of your NTP server, especially because those sources might change (if you use the NTP pool project for instance.

IMHO, It is better to use ntpq -c rv in order to get the ntp server kernel status (sync or not, stratum, rootdisp+rootdelay/2 (which is for me the maximum time difference to true UTC in ms), and offset (also in ms, but I'm still unsure of what that is exactly, ntp documentation is very unclear)). By far I'm not a NTP specialist, but I think those values gives you a better view of the "quality" of your NTP server than what ntpq -pn returns.

I'm also monitoring the frequency and sys_jitter returned value of ntpq -c rv but I'm not sure how to interpret them correctly.

For monitoring this, I'm using a simple script at the moment which loop around that command:

echo "ntpstats,host=$(hostname) $(ntpq -c "rv 0 offset,sys_jitter" | sed 's/ //g'),$(ntpq -c "rv 0 rootdisp,rootdelay" | sed 's/ //g')" | curl --silent --show-error -i -XPOST 'https://influxdb.lan:8086/write?db=telegraf' -u ${username}:${password} --data-binary  @- >/dev/null

Note: as one can see, I'm using the telegraf line protocol with an influxdb database, and grafana for display. But I want to investigate alternatives, hence my interest in prometheus.

[SuperQ]

@jcberthon Thanks for the helpful information. We can add this additional information to the existing helper script.

[SuperQ]

Some comments on the metrics so far.

rootdelay seems like it's the same thing as ntpd_delay_milliseconds where ntpd_peer_status == 6. for the same remote.

The other metrics I have no idea what they mean. But I can continue the research.

[SuperQ]

Hacked together a quick addition to the ntpd helper: #463

[brian-brazil]

Given the various ntp-related improvements made, is this still relevant?

[SuperQ]

No, this is obsolete.