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, 2024-01-04 at 14:40 +0100, Miroslav Lichvar wrote: 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. I have started a project here https://gitlab.com/markoh/chronysnmpd 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
