Discussion:
[chrony-users] check_ntp_peer with Chrony
Daniele Palumbo
2018-01-18 15:35:31 UTC
Permalink
Hi,

This post is quite long... sorry for that...

I need to monitor instances of chrony with icinga/nagios/...
I am on Debian Stretch, Chrony version 3.0-4+deb9u1.

I have seen a specific plugin on github, but i would like to keep it very straightforward.

So my goal has became to have monitoring-plugins check_ntp_peer working with Chrony.

https://github.com/monitoring-plugins/monitoring-plugins/blob/master/plugins/check_ntp_peer.c

From the following thread
https://support.nagios.com/forum/viewtopic.php?f=7&t=33845

Claim that this should be possible if NTPv4 is supported.
and Chrony does support NTPv4 (unicast).

Chrony already listen on 123 port, and i can use ntpdate to lookup for the time.

I have seen that a simple ntpdate request data in NTPv4, and the server does correctly reply.

But, check_ntp_peer will fail with timeout.
check_ntp_peer is asking instead for a NTPv2, for some reason.

# tcpdump -i any -n port 123 and host 172.16.8.102 -s0 -X
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
15:52:14.783472 IP XXX.XXX.XXX.XXX.56786 > XXX.XXX.XXX.XXX.123: NTPv2, Reserved, length 12
0x0000: 4500 0028 1cc7 4000 4011 b574 ac10 0866 E..(***@.@..t...f
0x0010: ac10 0803 ddd2 007b 0014 a2ec 1601 0001 .......{........
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............


NTPv2 is claimed to be supported since 1.28 version anyway,
https://git.tuxfamily.org/chrony/chrony.git/tree/NEWS?h=3.0&id=d5c507975c5ba5da32c9c7264dfde8b68a6140e5

Looking further, this call is READSTAT
# /usr/lib/nagios/plugins/check_ntp_peer -H XXX.XXX.XXX.XXX -vv
sending READSTAT requestcontrol packet contents:
flags: 0x16 , 0x01
li=0 (0x00)
vn=2 (0x10)
mode=6 (0x06)
response=0 (0x00)
more=0 (0x00)
error=0 (0x00)
op=1 (0x01)
sequence: 1 (0x01)
status: 0 (0x00)
assoc: 0 (0x00)
offset: 0 (0x00)
count: 0 (0x00)
CRITICAL - Socket timeout
recieving READSTAT response

Description is here:
https://github.com/monitoring-plugins/monitoring-plugins/blob/master/plugins/check_ntp_peer.c#L223

Thinking of a I have checked if any option would fit me, even in the latest release.
https://chrony.tuxfamily.org/doc/3.2/chrony.conf.html

I went throgh
cmdallow
option, but this is only for chronyc.

Not other options seems to me fitting.

I have tried to lookup into Chrony sources as well... no luck.

READSTAT seems to be defined (at least) in
https://tools.ietf.org/id/draft-odonoghue-ntpv4-control-00.html

That means, opcode 1
| 1 | read status command/response |

So, is there a flag that i have missed to support read status opcode in Chrony?
Or is this not currently possible at all?

Thank you very much,
Daniele
Miroslav Lichvar
2018-01-18 15:54:11 UTC
Permalink
Post by Daniele Palumbo
So my goal has became to have monitoring-plugins check_ntp_peer working with Chrony.
https://github.com/monitoring-plugins/monitoring-plugins/blob/master/plugins/check_ntp_peer.c
But, check_ntp_peer will fail with timeout.
check_ntp_peer is asking instead for a NTPv2, for some reason.
The version is not the problem here, but the mode of the packet is.
The plugin seems to be using mode 6 (control), which is not supported
by chrony. FWIW, it's not required or specified in the NTPv4
specification (RFC 5905).

Depending on what values you need to monitor, you may need a chrony
specific plugin, which uses the chronyc protocol (or just calling
chronyc), like this one:

https://exchange.nagios.org/directory/Plugins/Network-Protocols/NTP-and-Time/check_ntp(chrony)/details
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.
Daniele Palumbo
2018-01-18 16:25:02 UTC
Permalink
Post by Miroslav Lichvar
The version is not the problem here, but the mode of the packet is.
The plugin seems to be using mode 6 (control), which is not supported
by chrony. FWIW, it's not required or specified in the NTPv4
specification (RFC 5905).
Depending on what values you need to monitor, you may need a chrony
specific plugin, which uses the chronyc protocol (or just calling
Thank you for the quick reply.

It is much more clean now the topic.
Seems that the statement in the other ml is totally wrong.

I am anyway interested in checking if chrony does have proper source configured.
So the output of chronyc sources, not tracking.

I would like to monitor the status of the ntp sources, therefore something like from chronyc sources, i guess.

# chronyc sources
210 Number of sources = 2
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 000.000.000.007 2 6 377 0 -1925us[-1925us] +/- 21ms
^* 000.000.000.003 2 7 377 7 +1562us[+1544us] +/- 16ms

Given also the RFC in draft
https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/
That is not specific to ntpd (but write some comments specific for ntpd),

There may be some interest to developing mode 6 support?

Thank you very much,
Daniele
Miroslav Lichvar
2018-01-18 16:45:03 UTC
Permalink
Post by Daniele Palumbo
I would like to monitor the status of the ntp sources, therefore something like from chronyc sources, i guess.
# chronyc sources
210 Number of sources = 2
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 000.000.000.007 2 6 377 0 -1925us[-1925us] +/- 21ms
^* 000.000.000.003 2 7 377 7 +1562us[+1544us] +/- 16ms
Given also the RFC in draft
https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/
That is not specific to ntpd (but write some comments specific for ntpd),
There may be some interest to developing mode 6 support?
There is currently no interest in implementing the mode 6 protocol
as it allows traffic amplification, which is a security issue.

The protocol is described in draft-ietf-ntp-mode-6-cmds, but it has
informational status and AFAIK it's not intended for new
implementations.

That does not mean I'd not consider replacing the chronyc protocol
with a more standard protocol. I'm not sure what that would be yet.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.
Bill Unruh
2018-01-18 18:12:18 UTC
Permalink
You might also tell us what it is you want to learn, since it may be possible
that someone has a better way of doing so than using icinga or nagios...
Ie, you seem to have settled on a solution and are having problems
implimenting it, when the problem might have a much simpler solution.



William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ ***@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/
Post by Daniele Palumbo
Hi,
This post is quite long... sorry for that...
I need to monitor instances of chrony with icinga/nagios/...
I am on Debian Stretch, Chrony version 3.0-4+deb9u1.
I have seen a specific plugin on github, but i would like to keep it very straightforward.
So my goal has became to have monitoring-plugins check_ntp_peer working with Chrony.
https://github.com/monitoring-plugins/monitoring-plugins/blob/master/plugins/check_ntp_peer.c
From the following thread
https://support.nagios.com/forum/viewtopic.php?f=7&t=33845
Claim that this should be possible if NTPv4 is supported.
and Chrony does support NTPv4 (unicast).
Chrony already listen on 123 port, and i can use ntpdate to lookup for the time.
I have seen that a simple ntpdate request data in NTPv4, and the server does correctly reply.
But, check_ntp_peer will fail with timeout.
check_ntp_peer is asking instead for a NTPv2, for some reason.
# tcpdump -i any -n port 123 and host 172.16.8.102 -s0 -X
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
15:52:14.783472 IP XXX.XXX.XXX.XXX.56786 > XXX.XXX.XXX.XXX.123: NTPv2, Reserved, length 12
0x0010: ac10 0803 ddd2 007b 0014 a2ec 1601 0001 .......{........
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
NTPv2 is claimed to be supported since 1.28 version anyway,
https://git.tuxfamily.org/chrony/chrony.git/tree/NEWS?h=3.0&id=d5c507975c5ba5da32c9c7264dfde8b68a6140e5
Looking further, this call is READSTAT
# /usr/lib/nagios/plugins/check_ntp_peer -H XXX.XXX.XXX.XXX -vv
flags: 0x16 , 0x01
li=0 (0x00)
vn=2 (0x10)
mode=6 (0x06)
response=0 (0x00)
more=0 (0x00)
error=0 (0x00)
op=1 (0x01)
sequence: 1 (0x01)
status: 0 (0x00)
assoc: 0 (0x00)
offset: 0 (0x00)
count: 0 (0x00)
CRITICAL - Socket timeout
recieving READSTAT response
https://github.com/monitoring-plugins/monitoring-plugins/blob/master/plugins/check_ntp_peer.c#L223
Thinking of a I have checked if any option would fit me, even in the latest release.
https://chrony.tuxfamily.org/doc/3.2/chrony.conf.html
I went throgh
cmdallow
option, but this is only for chronyc.
Not other options seems to me fitting.
I have tried to lookup into Chrony sources as well... no luck.
READSTAT seems to be defined (at least) in
https://tools.ietf.org/id/draft-odonoghue-ntpv4-control-00.html
That means, opcode 1
| 1 | read status command/response |
So, is there a flag that i have missed to support read status opcode in Chrony?
Or is this not currently possible at all?
Thank you very much,
Daniele
--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.
Daniele Palumbo
2018-01-18 22:34:34 UTC
Permalink
Post by Bill Unruh
You might also tell us what it is you want to learn, since it may be possible
that someone has a better way of doing so than using icinga or nagios... Ie, you seem to have settled on a solution and are having problems
implimenting it, when the problem might have a much simpler solution.
Intro: i have asked to monitoring plugins guys to consider the problem, as check_ntp_peer is not documented on the fact that on openntpd and chrony is not working.
https://github.com/monitoring-plugins/monitoring-plugins/issues/1526

The goal:
I am already managing the environment with $automationsytems (let’s say puppet, but may be ansible or whatever) and i would like to check the time for all of the nodes.

Plus, i would like to check the status of my internal ntp servers, two for each site.

My preferred way to check it is to monitor on all of the nodes the numbers of available servers and its synchronization status.

In example, on ntp servers if i have less then 2 servers currently available and with less then 0.1 second (example) offset from the master, then trigger the alarm.
on ntp client, if i have less then 1 server currently available... you got the idea i think.

so, on ntp internal servers check_ntp_peer behavior is my preferred solution (see below for explanation).
Is fine to run it locally or remotely (currently local check through nrpe is performed with ntpd).

In my understanding, `chronyc sources` show the data needed to accomplish this output.
There is the offset, there is the stratum, there is the synchronization status with the remote server.
But as i am new to chrony, i may be totally wrong :)

What i would like to have, is a different way then `chronyc sources` output parsing (regexp?). Something more close to a protocol call/api approach.
Therefore i think chronyc protocol to call chronyd directly -- dunno if this is really possible to ask only for some data.

On the “clients” is fine to use something simpler, but the above may apply as well.
So, `chronyc tracking`.

Again, it would be awesome to query chrony directly, and avoid output parsing.

To have a comparison with the current provided solution with the standard monitoring tools, the check of time can be done in two way as highlighted above.
This make use of ntp protocol in both cases -even if with some mode not requested as to be implemented-, to the best of my knowledge.

check_ntp_peer
https://www.monitoring-plugins.org/doc/man/check_ntp_peer.html
Use this plugin to check the health of an NTP server. It supports
checking the offset with the sync peer, the jitter and stratum. This
plugin will not check the clock offset between the local host and NTP
server; please use check_ntp_time for that purpose.

With this, is possible also to check the available ntp sources.
This is not intended to check the local server time (even if, this is done if you are running it on the local system and ntp server is synchronizing the time).

If you need to check only the offset of the local system,

check_ntp_time
https://www.monitoring-plugins.org/doc/man/check_ntp_time.html
This plugin checks the clock offset between the local host and a
remote NTP server. It is independent of any commandline programs or
external libraries.

Hope this clarify,

Any suggestion is welcome,

Thank you very much for the support,
Daniele
Rob Janssen
2018-01-19 09:37:30 UTC
Permalink
I use this module on our Nagios system, which I based on one of the existing check modules and rewrote completely to use chronyc instead of ntpq.
But it uses the method of "run external program and parse output" which you apparently would want to avoid.  And it also does not monitor
everything you specificied, so you would have to modify it further.

Rob
Miroslav Lichvar
2018-01-19 09:55:52 UTC
Permalink
Post by Daniele Palumbo
What i would like to have, is a different way then `chronyc sources` output parsing (regexp?). Something more close to a protocol call/api approach.
Therefore i think chronyc protocol to call chronyd directly -- dunno if this is really possible to ask only for some data.
FWIW, parsing the csv output (-c option) is pretty straight forward.
In bash you could get the address and reachability with something like
this:

chronyc -c sources | while IFS=, read t s addr stratum poll reach rest; do
echo $addr $reach
done

But I agree this is not ideal. The plan is to provide a library that
could be used by C applications and later maybe add some bindings
for other languages.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.
Loading...