It would be nice if some of the values that cannot be obtained would be available via libchrony.
I will try to implement the ones that are clarified here.
Regarding low interest in the MIB in NTP WG I can understand it. However, we work in a business
where we monitor many systems and applications centrally (via SNMP), and NTP is one of
the key elements, and some of our applications are criticaly dependent on accurate time source
(multilateration, tracking,...). We monitor a lot of system parameters (CPU utilization, disk space,
memory utilization, etc.) via SNMP, and it would be very useful if we would be able to monitor
NTP with the same software. We have stratum 1 time sources synchonized with GPS, DCF,... which
can be easily jammed. Since the start of war in Ukraine and in Israel and Palestine, GNSS jamming
is more and more frequent and problematic. Therefore, monitoring chrony via SNMP would be very
beneficial probably not NTP WG, but for users.
On Thu, Dec 07, 2023 at 10:53:29AM +0000, Marko Hrastovec wrote:
libchrony looks like a good way to get the data from chrony and provide them
via SNMP.
Great.
The application builds and returns some data form chrony. However, NTPv4-MIB
was constructed with ntpd in mind and provides information more suited for ntpd.
Same problem is with the monitoring/control NTP mode 6. It assumes NTP
implementations have the same algorithms as ntpd. This is a frequent
topic in the NTP working group. There is some concensus that NTPv5
specification shouldn't prescribe any algorithms.
* ntpEntSoftwareVersion cannot be obtained via libchrony
There could be a new command for that and some other things below,
maybe called "serverinfo".
* ntpEntTimeResolution cannot be obtained via libchrony
I think this would be 1 nanosecond on all currently supported systems
in their latest versions.
* ntpEntTimePrecision not sure which value from libchrony to use
You could get it from an NTP response.
* ntpEntTimeDistance not sure which value from libchrony to use (probably "Last offset")
This would be root delay / 2 + root dispersion from the tracking report.
* ntpEntStatusEntityUptime cannot be obtained
Could be in serverinfo.
* ntpEntStatusLeapSecond cannot be obtained
Could be calculated from the leap status in tracking report as
midnight UTC of the current day.
* ntpEntStatusLeapSecDirection cannot be obtained
+1 or -1 per the leap status.
There are two options for minimize the difference between NTPv4-MIB and libchrony. First is
to add some values to libchrony. Second is to try to update NTPv4-MIB which is outdated and
was probably never used in full scale. The best would be the combination of both ways.
A new command to get some of the details would make sense to me. I can
look into it.
But at least in the NTP WG, I don't see much interest in the MIB. The
future seems to be the Yang model, see RFC 9249.
--
Miroslav Lichvar