Zeitsynchronisation von Servern prüfen: timedatectl, chronyc tracking und worauf alarmiert werden sollte

Ziel

Wissen, dass die Uhr jedes Hosts gegenüber einer vertrauenswürdigen Quelle diszipliniert wird und um wie viel sie gerade abweicht, und alarmiert werden, bevor der Unterschied für Anwendungen relevant wird.

Voraussetzungen

Ein Zeitdienst auf jedem Host (unter Linux sind systemd-timesyncd oder chronyd verbreitet), Netzwerkzugriff auf NTP-Server oder eine interne Zeitquelle sowie ein Monitoring-System, das einen Befehl ausführen oder eine Metrik abgreifen kann.

Schritte

1. Prüfen, dass ein Dienst aktiv ist und sich selbst als synchronisiert betrachtet. timedatectl gibt die Zeilen „System clock synchronized“ und „NTP service“ aus; sein Handbuch dokumentiert timesync-status für Details zu systemd-timesyncd und show-timesync für maschinenlesbare Ausgabe.
2. Auf chrony-Hosts chronyc tracking ausführen. Die chrony-Dokumentation erklärt die Felder: die Referenz-ID und den Namen des Servers, mit dem gerade synchronisiert wird, das Stratum (Anzahl Hops von einem Rechner mit angeschlossener Referenzuhr), den aktuellen Offset zwischen der NTP-Uhr von chronyd und der Systemuhr, letzten und RMS-Offset, Frequenz, Skew und Leap-Status. Sie besagt, dass eine Referenz-ID von 7F7F0101 ohne Namen oder Adresse bedeutet, dass der Rechner mit keiner externen Quelle synchronisiert ist und im lokalen Modus arbeitet.
3. Das Stratum lesen. RFC 5905 weist primären Servern Stratum eins zu und jeder Ebene darunter eine um eins höhere Zahl, und besagt, dass die Genauigkeit mit steigender Stratumzahl abnimmt; ein Host weit unten in der Hierarchie oder einer, der Stratum 16 meldet (in RFC 5905s Tabelle „unsynchronized“), ist keine brauchbare Uhr.
4. Zwei Fakten je Host als Metriken exportieren: synchronisiert (boolesch) und aktueller Offset in Sekunden. Alarmieren, wenn „synchronisiert“ über mehrere Abfrageintervalle hinweg falsch bleibt und wenn der absolute Offset eine Grenze überschreitet, die sich daran orientiert, was die Anwendungen tolerieren (Gültigkeitsprüfungen von Zertifikaten, Token-Lebensdauern, Ablauf von Leases).
5. Nach jedem Neustart und Image-Neubau prüfen, dass der Dienst aktiviert ist; ein Host, der mit einer falschen Hardware-Uhr und ohne laufenden Dienst startet, driftet unbemerkt.
6. In Containern gehört die Uhr dem Host: den Host prüfen und sicherstellen, dass Images keinen zweiten, widersprüchlichen Zeitdienst ausführen.
7. Gelegentlich Hosts paarweise vergleichen: Zwei Hosts, die je mit unterschiedlichen Upstreams „synchronisiert“ sind, aber weit auseinanderliegen, deuten auf einen fehlerhaften Upstream hin.

Erwartetes Ergebnis

Eine Ansicht des Synchronisationszustands und des Offsets je Host, ein Alarm, der auslöst, wenn ein Host still seine Zeitquelle verliert, und kein Vorfall, dessen erster Hinweis nicht zueinander passende Zeitstempel sind.

Grenzen und Prüfbasis

Vom Daemon gemeldete Offsets sind Schätzungen relativ zu seinen Quellen; eine Flotte, die mit einer einzigen falschen Quelle synchronisiert ist, zeigt überall einen Offset von null. Virtuelle Maschinen können nach dem Ruhezustand oder einer Migration springen; die Direktive makestep in chrony.conf bestimmt, ob ein grosser Offset gesprungen statt langsam angeglichen wird. Befehle und Felder folgen den zitierten Handbüchern; es wird kein akzeptabler Offset-Wert behauptet.