Ich habe einen Rocky Linux 9.2-Server. Wir überwachen ihn über check_mk und erhalten regelmäßig eine Warnung, dass die letzte Zeit seit der Synchronisierung 1 Stunde überschreiten kann. Beachten Sie, dass in den folgenden Quellen die Quelle mansfield.id.au bei 64 Minuten liegt.
Nach meinem begrenzten Verständnis von NTP entspricht das unten angegebene Maxpoll von 10 1024 Sekunden?
server 0.au.pool.ntp.org iburst minpoll 6 maxpoll 10
server 1.au.pool.ntp.org iburst minpoll 6 maxpoll 10
server 2.au.pool.ntp.org iburst minpoll 6 maxpoll 10
server 3.au.pool.ntp.org iburst minpoll 6 maxpoll 10
Tracking – nachdem Chrony endlich synchronisiert wurde, änderte sich das Aktualisierungsintervall auf 4135,0 Sekunden.
[]#chronyc tracking
Reference ID : 6EE87216 (mansfield.id.au)
Stratum : 3
Ref time (UTC) : Wed Jan 24 00:27:13 2024
System time : 0.000012703 seconds slow of NTP time
Last offset : -0.000079763 seconds
RMS offset : 0.000147473 seconds
Frequency : 10.848 ppm fast
Residual freq : -0.001 ppm
Skew : 0.052 ppm
Root delay : 0.032765601 seconds
Root dispersion : 0.005266702 seconds
Update interval : 1036.2 seconds
Leap status : Normal
Quellen
[]# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^- 192.9.171.167 2 10 377 254 +511us[ +511us] +/- 63ms
^* mansfield.id.au 2 10 377 64m -2117us[-2197us] +/- 19ms
^- ntp2.ds.network 2 10 377 1007 +16ms[ +16ms] +/- 173ms
^- 220-158-215-20.broadband> 2 10 377 943 +73us[ +73us] +/- 81ms
Weiß jemand, warum der Maxpoll-Wert scheinbar ignoriert wird, oder fehlt eine Konfiguration bzw. ist sie falsch?
Danke
jc
Antwort1
Das ist eine gesunde Chrony-Ausgabe. Vier Quellen, alle vor kurzem erreichbar, Präzision im Bereich unter 1 ms und Verzögerung im Zehntel von Millisekunden, und Sie sind 3 Hops (Stratum) von der Referenzuhr entfernt. Typisch für Internet-NTP-Server.
Ihre Ausgabe dort würde ich nicht als umsetzbar betrachten und daher nicht als Grund für eine Warnung. Es ist möglich, dass ein vorübergehendes Problem nach dem Auslösen der Warnung nicht mehr besteht oder dass die Prüfung fälschlicherweise auf Dinge hinweist.
Die Poll/Minpoll/Maxpoll-Konfiguration von chrony ist logarithmisch auf Basis 2, daher sind typische Werte von 10 1024 Sekunden. Ja, es ist normal, dass gesunde chrony-Instanzen die Pakete langsamer versenden und am Ende nur noch ein paar pro Stunde senden. Ein viel längeres Maxpoll ist möglich, aber ungefähr niemand ändert den Standardwert.
Ich kenne mich mit checkmk nicht aus. Glücklicherweise scheint es einen Open-Source-Kern mit dem Crony-Plugin zu haben. Ich gehe vonchrony.py getaggt v2.2.0. Dies sind die Schlüssel, die es aus chronyc trackingder Ausgabe extrahiert
Reference ID
System time
Stratum
Ref time (UTC)
Check verwendet die aktuelle Zeit abzüglich der analysierten Referenzzeit, um einen Schwellenwert für „Zeit seit der letzten Synchronisierung“ zu erstellen, wobei die Standardschwellenwerte anscheinend 1800 und 3600 Sekunden betragen. Es scheint fehleranfällig zu sein, eine formatierte Zeit analysieren zu müssen, aber zumindest werden Python-Bibliotheksfunktionen verwendet.
Ich denke, dieser Teil der Warnung ist sinnlos und nicht umsetzbar. Wenn die Synchronisierung fehlschlägt, wird die Fehlerschichtnummer 16 zurückgegeben, und die Prüfung warnt bereits bei Schicht > 10. Die Prüfung warnt auch, wenn eine IP-Adresse nicht aus der Referenz-ID analysiert werden kann. Und selbst wenn Chrony alle Eingaben verliert, wird die Uhr weiterhin auf der Grundlage bekannter Abweichungen diszipliniert.
Deaktivieren Sie den Verzögerungsteil dieser Prüfung. Oder setzen Sie ihn zumindest auf einen viel höheren Schwellenwert, vielleicht 1 oder 2 Tage. Es ist mir egal, dass das letzte NTP-Paket vor 30 Minuten war, aber 30 Stunden auf einem Always-On-Server ohne Referenzuhrmessung könnten interessant sein.
Diversifizieren Sie Ihre Quellen auch, indem Sie Quellen außerhalb des Internets einbeziehen. Wenn Sie mit Hardware arbeiten, können Sie NTP-Geräte erhalten, wahrscheinlich von einem Satellitensignal. Oder es gibt möglicherweise bereits einen NTP-Server im lokalen Netzwerk, in einigen Clouds gibt es einen als Teil eines Metadatendienstes.