Univention-Nagios NTP Sensor Problem

UCS - Univention Corporate Server
#1

Hallo,

über den Changelog der 3.x Versionen bin ich darauf gekommen, dass Univention etwas am Nagios-Sensor für die NTP-Überwachung verbessert hat.

Wir verwenden 4.0-1 auf Patchstand 03-2015 und damit bekomme ich seit einem der letzten Patches regelmäßig (täglich auch 10x) sowas:

** PROBLEM Service Alert: ucs.somedomain.tld/UNIVENTION_NTP is CRITICAL **

***** Nagios *****

Notification Type: PROBLEM

Service: UNIVENTION_NTP
Host: ucs.somedomain.tld
Address: 192.168.xxx.xxx
State: CRITICAL

Date/Time: Tue Mar 31 17:33:56 CEST 2015

Additional Info:

NTP CRITICAL: Offset unknown

Aufgrund dessen habe ich letztens mehrfach versucht, von unserem internen NTP, welcher sich die Zeit von pool.ntp.org holt und dem internen Netz zu Verfügung stellt, sofort per Abfrage die Zeit zu holen. Dies funktioniert von einem anderen Linux problemlos (natürlich vergehen einige Sekunden, bis ich das nach der Fehlermeldung testen kann).
Nach 10 Minuten gibt es dann immer die Gutmeldung:

** RECOVERY Service Alert: ucs.somedomain.tld/UNIVENTION_NTP is OK **

***** Nagios *****

Notification Type: RECOVERY

Service: UNIVENTION_NTP
Host: ucs.somedomain.tld
Address: 192.168.xxx.xxx
State: OK

Date/Time: Tue Mar 31 17:43:56 CEST 2015

Additional Info:

NTP OK: Offset -1.537799835e-05 secs

Es gibt in der Univention Config-Registry Felder für 3 NTP Server, wahrscheinlich werden diese per Failover nacheinander abgefragt. Wir haben zur Zeit nur einen gesetzt.

Ich wundere mich, warum das erst jetzt Probleme macht, da wir an der restlichen Konfiguration nichts geändert haben, insbesondere am internen NTP, abgesehen von den UCS Updates.

Vielleicht hat jemand ähnliche Probleme bzw. eine Idee?

Beste Grüße,
TP

#2

Hallo,

ich sehe das auch sporadisch. Im Moment hab ich dazu erstmal nur Ansätze zum Weitersuchen.

Weil ich damit schon mal viel Zeit versenkt habe, schreibe ich diesmal alles auch zur eigenen Dokumentation auf.

[bug]34570[/bug] hat check_ntp_time anstelle check_ntp eingeführt.

Der Nagios-Check sieht ist definiert als:

[code]# udm nagios/service list --filter name=UNIVENTION_NTP | grep checkCommand
checkCommand: check_univention_ntp

root@master:/etc/nagios-plugins/config# grep -A 4 ‘check_univention_ntp’ univention.cfg

‘check_univention_ntp’ command definition

define command{
command_name check_univention_ntp
command_line /usr/lib/nagios/plugins/check_ntp_time -H ‘$HOSTNAME$’ -w ‘$ARG1$’ -c ‘$ARG2$’
}
[/code]

Der Fehler wird von diesem Plugin geworfen.

root@master:/etc/nagios-plugins/config# dpkg -S check_ntp_time nagios-plugins-basic: /usr/lib/nagios/plugins/check_ntp_time root@master:/etc/nagios-plugins/config# apt-cache policy nagios-plugins-basic nagios-plugins-basic: Installiert: 1.4.16-1.36.201409291807 Installationskandidat: 1.4.16-1.36.201409291807 Versionstabelle: *** 1.4.16-1.36.201409291807 0 500 http://updates.software-univention.de/4.0/maintained/ 4.0-0/amd64/ Packages 100 /var/lib/dpkg/status

Im Netz findet man Hinweise auf Probleme von check_ntp_time im Kontext der “Leap Second”. Die ist aber erst am 30.6.
Bemerkenswert ist allerdings, dass bei Ihnen der Fehler am Tag nach der DST-Umstellung auftrat. Wobei ich ihn letztmalig am 8.3. gesehen habe. Da war aber nur Internationaler Frauentag, dürfte also nicht in einem Zusammenhang stehen.

Vielleicht findet jemand anderes noch aktuellere Hinweise. Die Bugs im Kontext sollten in dieser Version von nagios-plugins-basic behoben sein.

Viele Grüße,
Dirk Ahrnke

#3

Hallo,

Der Fehler trat schon vor der DST-Umstellung auf, nur in unterschiedlicher Häufigkeit. Es könnte natürlich auch mit einem unzuverlässigen NTP-Server im Pool zusammenhängen. Momentan erhalte ich jedenfalls etwas weniger Meldungen diesbezüglich!

Ob der internationale Frauentag für Risse im Raum/Zeitkontinuum verantwortlich sein kann, konnte ich bis jetzt leider auch noch nicht eruieren… :wink:

Beste Grüße,
TP

#4

Hallo,

das Problem ist laut mir mit den letzten Update behoben worden (oder der verantwortliche NTP-Server passt wieder).

Beste Grüße,
TP

Mastodon