Hallo,
ich habe hier aktuell massive Probleme mit dem NTP check.
Ich bin mir aber noch nicht sicher ob das seit dem Update auf Version 11 der Fall ist oder ob ich tatsächlich ein Problem habe das zu lösen ist.
Hat jemand ähnlicher Erfahrungen?
Und wie äußern sich diese Probleme konkret?
Kannst du die Meldung/Interpretation von Checkmk auch auf dem Client selbst nachvollziehen (im ntpd, chrony oder was eben eingesetzt wird)?
Ich bekomme Crits last sync grösser X und stratum > X.
Es kann sein das unseren zuständigen Kollegen da wieder was umgefallen ist aber bevor ich denen tief in die Augen schaue will ich klären ob ich ggf. “nur” ein Problem mit dem Monitoring habe.
Gruß
Das klingt nach klarer Ansage und sollte sich ja recht schnell auf einem der betroffenen Systeme verifizieren lassen.
ntpq -p
oder chronyc tracking; chronyc sources
oder systemctl status systemd-timesyncd.service
oder …
Danke,
werde ich prüfen.
Gruß
Uih,
ich sehe gerade das meine Regeln nicht mehr ziehen.
Es werden die defaults Stratum (10/10) gezogen obwohl ich 14 /14 konfiguriert und aktiviert habe.
Da scheint mehr kaputt zu sein.
Gruß
Wir sehen die gleiche Sache gehen von 09 bis 11 zufällig über Hosts, aber die meisten von ihnen sind rechts um 30min zeigen und dann 5 Minuten später ist es gelöscht.
NTP-Server: (142.147.92.5)
Referenz-ID: 8E935C05 (142.147.92.5)
Abweichung: 0,3632 ms
Schicht: 3
Zeit seit der letzten Synchronisierung: 30 Minuten 30 Sekunden (Warnung/Kritik bei 30 Minuten 0 Sekunden/1 Stunde 0 Minuten)WARN
Ich habe eine Regel erstellt, um die Warnung/crt für Systemd Timesyncd Zeitsynchronisation auf 2 Stunden/Warnung und 3/crt zu verschieben, aber das hat nicht geholfen.
Verwendete Website für die Übersetzung aus dem Englischen.
Übersetzt mit www.DeepL.com/Translator (kostenlose Version)
Alles ab Stratum 10 bedeutet nicht synchronisiert oder halt nur mit seiner eigenen CMOS Uhr.
Ich würde auch wie @martin.schwarz sagen es ist eindeutig dein NTP kaputt auf den Systemen 
@rickb keep the text in English it’s better - i don’t know why DeepL produces such strange German here, it could be the technical background
Ich habe ein ähnliches, wenn nicht sogar das gleiche Problem. Hab letzte Woche 2.0.0p11 (CEE) installiert und auch den Agent auf alle Hosts ausgerollt. Nun habe ich auch bei einigen Linuxsystemen o.g. Phänomen. zusätzlich geht der Dienst “NTP-Time” aber auf stale. Auf den System läuft der Agent unter systemd (nicht xinetd) und für die Zeitsynchronisation wird chrony verwendet. Nun habe ich aber festgestellt, dass die Datei /var/lib/check_mk_agent/cache/chrony.cache offenbar nur beim Erstmaligen abrufen geschrieben wird. Bei den weiteren Abfragen, wird sie nicht erneuert.
Soweit ich das verstanden habe, sollte sie aber nach spätestens 30 Sekunden erneuert werden. Mein Checkintervall steht auf 1 Minute.
Rufe ich am entsprechenden Host auf der Kommandozeile den check_mk_agent zum testen auf, wird die Datei aktualisert.
Auf Systemen auf denen der Agent mit xinetd aufgerufen wird, scheint das Problem nicht aufzutreten.
Das scheint aber hier ein Bug zu sein im aktuellen Linux SystemD Agent. Dort wurde eine extra Unit neu angelegt welche sich um asynchrone Checks kümmern soll. Hab mir das selbst noch nicht angeschaut klingt aber stark nach einem Problem dort.
@moritz kennt sich damit aus 
Ja hab ich auch in der Zwischenzeit gemerkt. Sind offenbar alle Bereiche, die den cached-Modus verwenden davon betroffen. Unter anderem hab ich den Fehler auch bei Zypper Updates gefunden.
Sieht so aus, dass beim Updaten auf die neue Version über die Bakery die entsprechende Unit am Linux-Host nicht mitgestartet wird.
systemctl start check-mk-agent-async
auf den betroffenen Systetemen brachte bei mir erst mal Abhilfe. Mal beobachten, ob der Fehler damit behoben ist.
Nachtrag:
systemctl enable check-mk-agent-async
Wird benötigt damit das Ganze auch noch nach einem Neustart funktioniert
Weiss jemand gerade mit welchem Update der async Service reingekommen ist?
Ich habe nur mit bestimmten OS Probleme momentan. Aber ich glaube da hat es bei uns einen Mix zwischen xinetd und systemd gegeben.
Ist ab p11 vorhanden wenn ich mich nicht verlesen hab im Source. In der p9 war das noch nicht da.
1 Like
Laut werks kam es bereits mit der p10 werk# 12907
ups sehe gerade, dass die p10 gar nicht freigegeben wurde. Also doch mit p11
1 Like
Danke, im Changelog innerhalb von Checkmk fand ich es so nicht, aber jetzt ist es klar. Thx to @andreas-doehler & @nobbiew
Das ist sehr komisch. Die Statements zum starten/enablen des Service sollten eigentlich in das Postinstall-Skript gebacken sein, und bei einem Paket das ich heute analysiert habe waren sie das auch.
Trotzdem war der Service im Status “disabled / vendor preset: enabled”. Könnt ihr das bestätigen? Um welche Distros geht es? Und passiert das bei jedem Agentupdate wieder? Was sagt das Updater Log?
EDIT: Bitte einen neuen Thread zu diesem Thema starten, und mich da anpingen. Dann können wir hier beim thema NTP bleiben.
Ein letzter Hinweis: Die IP Beschränkung (WATO Allowed agent access via IP address) verträgt sich nicht mit systemd Versionen < 2.3.5. Debian stretch zu Beispiel.
sorry @rprengel, das derailt jetzt etwas 
. Zu NTP: Seit der p11 ist das asynchrone Ausführen mit systemd repariert. Weil das kaputt war, ging das vorher. Probier mal im Agent das run_cached wegzulassen, und das direkt mit waitmax aufzurufen.
Ok,
gerne aber wie mache ich das.
Ich bin nicht so tief in drin im Thema client config.
Gruß
Ralf