| Re: [chrony-dev] SNMP agent |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
- To: chrony-dev@xxxxxxxxxxxxxxxxxxxx
- Subject: Re: [chrony-dev] SNMP agent
- From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
- Date: Thu, 4 Jan 2024 14:40:04 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1704375606; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vm/HChN+5WewsTaDDM68ZwI4dXwSaFxztCxN3OWkxKQ=; b=Pqg+Dx/zz7Yh+O0ulL6eRW8v2axsxwGFAtErVoIF89r6MEIrS4o1wDDoHVZcvETzZLN2zz pkVMvWg2SCuIqDHDiVtOHmS+Kh0J4W+S5sjll0M2zWmpn92TjZa7/suhGhN60fl32N0/bZ D6ZetMH3IT2FZqVm4A+qg6ShK/FUfAw=
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-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.