Re: nagios monitoring of a remote openntp service
On Thursday, 08.05.2008 at 11:53 +0200, Pete Vickers wrote: Has anybody gotten Nagois' check_ntp_* to play nicely with a remote openntp service ? It appears to rely upon services not implemented in openntp ? openntpd does not listen on port 123 by default: that's what Nagios would use to monitor, Check man ntpd.conf for the 'listen' option. Dave. -- Dave Ewart [EMAIL PROTECTED], jabber:[EMAIL PROTECTED], freenode:davee All email from me is now digitally signed, http://www.sungate.co.uk/ Fingerprint: AEC5 9360 0A35 7F66 66E9 82E4 9E10 6769 CD28 DA92
Re: nagios monitoring of a remote openntp service
Hi, That's not the problem ! - the hosting is correctly listening, and indeed other hosts are correctly syncing to it. It's only the nagios check_ntp_* that doesn't like it. $ ~ grep -i listen /etc/ntpd.conf # Addresses to listen on (ntpd does not listen by default) listen on * $ ~ ps -aux | grep ntp _ntp 18182 0.0 0.0 468 612 ?? S 19Nov065:57.94 ntpd: ntp engine (ntpd) root 10889 0.0 0.0 512 616 ?? Is19Nov060:00.24 ntpd: [priv] (ntpd) /Pete On 8 May 2008, at 12:59 PM, Dave Ewart wrote: On Thursday, 08.05.2008 at 11:53 +0200, Pete Vickers wrote: Has anybody gotten Nagois' check_ntp_* to play nicely with a remote openntp service ? It appears to rely upon services not implemented in openntp ? openntpd does not listen on port 123 by default: that's what Nagios would use to monitor, Check man ntpd.conf for the 'listen' option. Dave. -- Dave Ewart [EMAIL PROTECTED], jabber:[EMAIL PROTECTED], freenode:davee All email from me is now digitally signed, http://www.sungate.co.uk/ Fingerprint: AEC5 9360 0A35 7F66 66E9 82E4 9E10 6769 CD28 DA92
Re: nagios monitoring of a remote openntp service
On 2008-05-08, Pete Vickers [EMAIL PROTECTED] wrote: Has anybody gotten Nagois' check_ntp_* to play nicely with a remote openntp service ? It appears to rely upon services not implemented in openntp ? this is against an OpenNTP server; [EMAIL PROTECTED]:12$ /usr/local/libexec/nagios/check_ntp_time -H ntp NTP OK: Offset -0.002711469308 secs|offset=-0.002711s;60.00;120.00; so, it can work.
Re: nagios monitoring of a remote openntp service
that works fine: $ ~/usr/local/libexec/nagios/check_ntp_time -H ntp1 NTP OK: Offset 0.0008395434124 secs|offset=0.000840s; 60.00;120.00; but, I'm trying to verifty the NTP server's health, not that my monitoring host is sync'd to it. Notes: 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. If you'd rather want to monitor an NTP server, please use check_ntp_peer. but that doesn't work (for me) : $ ~/usr/local/libexec/nagios/check_ntp_peer -H ntp1 -t 3 CRITICAL - Socket timeout after 3 seconds /Pete On 8 May 2008, at 1:55 PM, Stuart Henderson wrote: On 2008-05-08, Pete Vickers [EMAIL PROTECTED] wrote: Has anybody gotten Nagois' check_ntp_* to play nicely with a remote openntp service ? It appears to rely upon services not implemented in openntp ? this is against an OpenNTP server; [EMAIL PROTECTED]:12$ /usr/local/libexec/nagios/check_ntp_time -H ntp NTP OK: Offset -0.002711469308 secs|offset=-0.002711s; 60.00;120.00; so, it can work.
Re: nagios monitoring of a remote openntp service
On Thursday, 08.05.2008 at 13:29 +0200, Pete Vickers wrote: Has anybody gotten Nagois' check_ntp_* to play nicely with a remote openntp service ? It appears to rely upon services not implemented in openntp ? openntpd does not listen on port 123 by default: that's what Nagios would use to monitor, Check man ntpd.conf for the 'listen' option. That's not the problem ! - the hosting is correctly listening, and indeed other hosts are correctly syncing to it. It's only the nagios check_ntp_* that doesn't like it. On this network, Nagios runs on a Debian Etch machine and issuing: /usr/lib/nagios/plugins/check_ntp -H myhostname returns NTP OK: Offset -0.0001729539945 secs|offset=-0.0001729539945 What output do *you* get when you run check_ntp? Dave. -- Dave Ewart [EMAIL PROTECTED], jabber:[EMAIL PROTECTED], freenode:davee All email from me is now digitally signed, http://www.sungate.co.uk/ Fingerprint: AEC5 9360 0A35 7F66 66E9 82E4 9E10 6769 CD28 DA92
Re: nagios monitoring of a remote openntp service
On 2008/05/08 14:33, Pete Vickers wrote: that works fine: $ ~/usr/local/libexec/nagios/check_ntp_time -H ntp1 NTP OK: Offset 0.0008395434124 secs|offset=0.000840s;60.00;120.00; but, I'm trying to verifty the NTP server's health, not that my monitoring host is sync'd to it. check_ntp_time should be fine for that. Notes: 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. If you'd rather want to monitor an NTP server, please use check_ntp_peer. I think that's just useful for ISC ntpd, it checks stratum.
Re: nagios monitoring of a remote openntp service
On Thu, 2008-05-08 at 14:33 +0200, Pete Vickers wrote: that works fine: $ ~/usr/local/libexec/nagios/check_ntp_time -H ntp1 NTP OK: Offset 0.0008395434124 secs|offset=0.000840s; 60.00;120.00; but, I'm trying to verifty the NTP server's health, not that my monitoring host is sync'd to it. Nagios checks almost never have sufficient debugging mechanisms, and UDP services dont send RST+ICMP. You an always: $ sudo ntpdate -qdv [host to check] ~BAS Notes: 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. If you'd rather want to monitor an NTP server, please use check_ntp_peer. but that doesn't work (for me) : $ ~/usr/local/libexec/nagios/check_ntp_peer -H ntp1 -t 3 CRITICAL - Socket timeout after 3 seconds /Pete On 8 May 2008, at 1:55 PM, Stuart Henderson wrote: On 2008-05-08, Pete Vickers [EMAIL PROTECTED] wrote: Has anybody gotten Nagois' check_ntp_* to play nicely with a remote openntp service ? It appears to rely upon services not implemented in openntp ? this is against an OpenNTP server; [EMAIL PROTECTED]:12$ /usr/local/libexec/nagios/check_ntp_time -H ntp NTP OK: Offset -0.002711469308 secs|offset=-0.002711s; 60.00;120.00; so, it can work. -- Brian A. Seklecki [EMAIL PROTECTED] Collaborative Fusion, Inc.
Re: nagios monitoring of a remote openntp service
On Thu, May 8, 2008 at 8:52 AM, Brian A. Seklecki
[EMAIL PROTECTED] wrote:
Nagios checks almost never have sufficient debugging mechanisms, and UDP
services dont send RST+ICMP.
you should get an ICMP port unreachable if there is no UDP service listening.
i haven't looked at nagios, but i wonder if it's not trying to use NTP
mode 6 control messages to get more status information out of the
daemon. openntpd doesn't support these queries...
You an always: $ sudo ntpdate -qdv [host to check]
or rdate -pnv host. quite some time ago i added a check to make
rdate bail out if the server is unsync'd.
...
if ((data.status STATUS_ALARM) == STATUS_ALARM) {
warnx(Ignoring NTP server with alarm flag set);
return (-1);
}
...
CK
--
GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: nagios monitoring of a remote openntp service
On 2008-05-08, Chris Kuethe [EMAIL PROTECTED] wrote:
On Thu, May 8, 2008 at 8:52 AM, Brian A. Seklecki
[EMAIL PROTECTED] wrote:
Nagios checks almost never have sufficient debugging mechanisms, and UDP
services dont send RST+ICMP.
you should get an ICMP port unreachable if there is no UDP service listening.
i haven't looked at nagios, but i wonder if it's not trying to use NTP
mode 6 control messages to get more status information out of the
daemon. openntpd doesn't support these queries...
check_ntp_peer does exactly that.
You an always: $ sudo ntpdate -qdv [host to check]
or rdate -pnv host. quite some time ago i added a check to make
rdate bail out if the server is unsync'd.
...
if ((data.status STATUS_ALARM) == STATUS_ALARM) {
warnx(Ignoring NTP server with alarm flag set);
return (-1);
}
...
CK
check_ntp_time says NTP CRITICAL: Offset unknown| if that happens,
same as if the server isn't running. Not quite as much information as it
could give, but if you're basically looking to be alerted when your server
is broken, it's still helpful.
