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


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Reply via email to