Hi,
ich habe festgestellt, dass in unserer CheckMK Umgebung (1.6.0p19) einige Hosts, bei denen die Agent Execution Time (“Time spent waiting for Check_MK agent”) etwas höher ist, der NTP Check bei jedem zweiten Durchlauf als Stale eingestuft wird. In der Cache Datei /var/lib/check_mk_agent/cache/chrony.cache sehe ich, dass der Unix Timestamp das Alter der Daten bestimmt. Auf einem Server, bei dem der CheckMK Agent für einen Durchlauf 10 Sekunden benötigt (Grund: Docker Checks), wird die Datei und der enthaltene Timestamp alle 70 Sekunden aktualisiert. Auf einem vergleichbaren System ohne Docker mit Execution Time im Millisekundenbereich passiert dies nicht, dort wird die Datei bei jedem Durchlauf, also alle 60 Sekunden aktualisiert.
Hat schon jemand die gleichen Erfahrungen gemacht und einen Vorschlag zur Verbesserung?
Der Timestamp im Cache File hat eigentlich nix mit dem Stale Status zu tun. Es ist hier eher das Problem, dass der Chrony Check scheinbar nur alle 2 Abfragen bei dir Daten überträgt.
Hier gibt es bei deinem Agent aber scheinbar ein Problem.
Normales Verhalten
Cache Age für Chrony Check ist 30 Sekunden damit wird der Chrony Check eigentlich bei jedem Abfrageintervall neu ausgeführt und wieder gespeichert
Der Agent gibt die Cache Datei aus wenn dieser älter als die angegebene Zeit ist (sollte hier immer der Fall sein) und erzeugt einfach eine neue aktuelle
Wo hier dein Problem liegt kann maximal jemand mit bisl mehr Bash Know-How sagen
erstmal großen Dank an Dich für deine schnelle Rückmeldung! Ich hab mal etwas weiter recherchiert und folgendes festgestellt:
Cache Age von 30 bewirkt, wie Du schon gesagt hast, dass der Check bei jedem Abfrageinterval ausgeführt wird. Agentseitig sehe ich auch, dass die lokale Datei /var/lib/check_mk_agent/cache/chrony.cache alle ~60s auf dem einen und alle ~70s auf dem anderen aktualisiert wird. So weit so gut, der Agent aktualisiert also bei jedem Durchlauf.
Auf dem CheckMK Server habe ich mir die zugehörigen Cache Dateien in ~/tmp/check_mk/cache/ mit dieser While-Schleife angeschaut: :~$ while :; do cts=$(grep -aoE "[0-9]{10},30" tmp/check_mk/cache/server-a); echo $(($(date +%s) - ${cts::-3})); sleep 1; done
Die Schleife vergleicht den Zeitstempel des NTP Checks aus der Datei mit dem momentanen Zeitstempel und gibt die Differenz aus. Dabei kann ich sehen, dass auf Server A mit einer Execution Time im Millisekundenbereich die Differenz nie mehr beträgt als 121 Sekunden. Bei Server B wächst die Differenz bis auf 145 Sekunden an, weil dort die Execution Time des Agents ~10s beträgt. Das Webinterface interpretiert diesen Stand dann als Stale.
Was ist jetzt noch nicht ganz verstehe ist die Ausgabe im Webinterface: Sobald “The time since the last check of the service” 120(?) Sekunden überschreitet, werden die Daten aus dem Cache als Stale angesehen. Die Dateien /var/lib/check_mk_agent/cache/chrony.cache und tmp/check_mk/cache/server-a sind ja aber “aktuell” - also werden bei jedem Interval neu geschrieben. Ist dieser Schwellenwert definierbar?
Der Stale Wert ist konfigurierbar aber nur Global. Da das Webinterface dies einfach nur selber interpretiert und anzeigt. Global Settings einfach mal nach “stale” suchen.
Eine deiner Beobachtungen ist interessant - Ich weiß nicht warum die Differenz deiner Timestamps über 2 Minuten beträgt. Wenn dein Check Interval 1 Minute ist. Normal dürfte diese Differenz nie mehr wie 60-70 Sekunden betragen.
Warum der Check bei über 120 Sekunden Stale anzeigt kann ich kurz erklären.
Default stale Wert ist 1,5 Check Intervalle (1,5 Minuten alt) + 30 Sekunden Cache Time = 120 Sekunden.
Nja, ich habe ein ähnliches Phänomen, mit NTP synch, rechne da allerdings mit einem anderen Problem. Folgender Effekt tritt auf. Wenn NTP Server über DNS aufgelöst wird, haben wir je nach Vlan einen Zeitversatz von 20-40 Sekunden, obwohl wir den einen uns selben NTP Server abfragen. Wird dies nun über die statische IP statt über den DNS aufgelöst, sind alle Server und VMS in der selben Sekunde synchronisiert… Ev. könnte diese Erkenntnis hilfreich sein? Grund dafür ist mir bis heute unklar. Hatte jedoch kaum Zeit da mal nachzugehen…
Im Grunde der selbe Befehl, nur auf die jeweils unterschiedlichen Dateien. Der Befehl gibt zu erst die aktuelle Zeit aus, dann den Zeitstempel wann die Datei zuletzt geändert wurde, dann den Zeitstempel der Chrony Daten aus der Datei und zuletzt die Differenz im Vergleich zum aktuellen Zeitstempel.
Führt man die Befehle zeitgleich auf beiden Systemen aus, sieht man, dass nach dem Durchlauf vom Agent, die Daten auf dem CMK Server bereits “veraltet” sind. In der zweite Zeile sieht man recht gut, dass der Agent grad lief und alle drei Zeitstempel identisch sind (1607497961). In der vierten Zeile (9 Sekunden später) kommt allerdings der Zeitstempel 1607497895 an - der zu diesem Zeitpunkt dann schon eine gute Minute alt ist:
Server-A
CMK Server
Current Time: 1607497958 (Wed Dec 9 08:12:38 CET 2020) File age: 1607497895 (Wed Dec 9 08:11:35 CET 2020) Cache age: 1607497895 (Wed Dec 9 08:11:35 CET 2020) Deviation: -63
Current Time: 1607497958 (Wed Dec 9 08:12:38 CET 2020) File age: 1607497900 (Wed Dec 9 08:11:40 CET 2020) Cache age: 1607497829 (Wed Dec 9 08:10:29 CET 2020) Deviation: -129
Current Time: 1607497961 (Wed Dec 9 08:12:41 CET 2020) File age: 1607497961 (Wed Dec 9 08:12:41 CET 2020) Cache age: 1607497961 (Wed Dec 9 08:12:41 CET 2020) Deviation: -0
Current Time: 1607497961 (Wed Dec 9 08:12:41 CET 2020) File age: 1607497900 (Wed Dec 9 08:11:40 CET 2020) Cache age: 1607497829 (Wed Dec 9 08:10:29 CET 2020) Deviation: -132
Current Time: 1607497964 (Wed Dec 9 08:12:44 CET 2020) File age: 1607497961 (Wed Dec 9 08:12:41 CET 2020) Cache age: 1607497961 (Wed Dec 9 08:12:41 CET 2020) Deviation: -3
Current Time: 1607497964 (Wed Dec 9 08:12:44 CET 2020) File age: 1607497900 (Wed Dec 9 08:11:40 CET 2020) Cache age: 1607497829 (Wed Dec 9 08:10:29 CET 2020) Deviation: -135
Current Time: 1607497969 (Wed Dec 9 08:12:49 CET 2020) File age: 1607497961 (Wed Dec 9 08:12:41 CET 2020) Cache age: 1607497961 (Wed Dec 9 08:12:41 CET 2020) Deviation: -8
Current Time: 1607497969 (Wed Dec 9 08:12:49 CET 2020) File age: 1607497966 (Wed Dec 9 08:12:46 CET 2020) Cache age: 1607497895 (Wed Dec 9 08:11:35 CET 2020) Deviation: -74
Müsste nicht der aktuellere Zeitstempel übertragen werden?
Hallo, abgesehen davon, das der MGMT Bereicht alles mit MTU 1500 konfiguriert ist. Wie soll denn ein MTU Fehler, bei DNS Auflösung eine so grosse Verzögerung hervorrufen und bei statische IP keine. Bei der DNS Auflösung holt der Server lediglich die IP ab und stellt dann die gleiche Anfrage an den NTP Server, mit der statischen IP macht er dies einfach direkt…
MTU prüfung über check mk, gibt es dazu eine Wegleitung? Ist ein Thema was ich noch im Hinterkopf habe, dass Check MK MTU missmatch aufzeigen kann. Nur wie? Hab da aber den Fokus aufs Produktiv Netz, sprich Kundennetz …
Das DNS / NTP ist ja weithin bekannt. Sobald beim klassischen ntpd DNS Namen verwendet werden kann eine Abfrage sehr sehr lange dauern. Gleicher Zielhost per IP ist schnell.
Zu dem eigentlichen Timestamp Problem fällt mir nix weiter ein. Würde hier eher dafür plädieren wenn die Ergebnisse zuverlässig ankommen dann ist das auch ok wenn das Ergebnis 1-2 Minuten alt ist.
