Zusammenfassung

  • timeQuality beschreibt die eigene Einschätzung des Syslog-Senders zu Zeitzone, Synchronisierung und möglicher Abweichung; der Empfänger prüft damit nicht unabhängig die Uhr.
  • syncAccuracy begrenzt die vom Sender erwartete Abweichung zwischen Synchronisierungen. Belastbar wird die Angabe erst durch eine zuverlässige Zeitquelle und passende Betreiberkonfiguration.

Eine Zahl, aber kein Messprotokoll

Das Beispiel in RFC 5424 ist leicht misszuverstehen, weil es eine konkrete Größenordnung nennt. syncAccuracy="60000000" bedeutet 60 Millionen Mikrosekunden, also 60 Sekunden. Bei einer Nachricht mit Zeitstempel 09:00 Uhr veranschaulicht die Spezifikation damit ein mögliches Fenster von 08:59 bis 09:01. Die Zahl wirkt messbar und präzise. Sie ist jedoch die Erwartung des Senders für die maximale Abweichung zwischen zwei Synchronisierungsintervallen, nicht das Ergebnis einer externen Messung.

Genau diese Lesart macht die optionale timeQuality-Struktur nützlich. Die Abschnitte 6.2.3 und 7.1 von RFC 5424 behandeln zunächst die Darstellung eines TIMESTAMP – in einer eingeschränkten Form von RFC 3339 – und dann die Möglichkeit, die Einschätzung des Senders zur Systemzeit mitzuführen. Ein gültig formatierter Zeitstempel und die Grundlage, ihm zu vertrauen, sind zwei verschiedene Aussagen.

Abschnitt 7.1 empfiehlt, timeQuality zu schreiben, wenn der Ursprung nicht ordnungsgemäß mit einer zuverlässigen externen Quelle synchronisiert ist oder nicht weiß, ob seine Zeitzonenangaben stimmen. Die Parameter bleiben optional: Der Sender kann eine Einschränkung offenlegen, ohne jedes Detail ausfüllen zu müssen.

Drei Angaben mit verschiedenen Voraussetzungen

tzKnown sagt aus, ob der Sender seine Zeitzoneninformation kennt. Die Darstellung in UTC beantwortet diese Frage nicht: Auch ein Zeitstempel mit Z kann aus einer bekannten Zeitzonenkonfiguration stammen. Umgekehrt beweist UTC allein keine korrekte lokale Einstellung. Anhang A.7 empfiehlt einen vorsichtigen Standard und verweist auf Konfiguration oder Prüfung durch den Administrator, bevor die Zeitzone als bekannt gilt.

isSynced teilt mit, ob sich der Absender mit einer zuverlässigen externen Quelle wie NTP synchronisiert sieht. Die Syslog-Nachricht enthält aber keine unabhängige Abfrage dieser Quelle. Ein Collector liest, was der Sender eingetragen hat. Der Betriebszustand des Zeitdienstes muss aus dessen eigener Überwachung kommen.

syncAccuracy benennt als Ganzzahl in Mikrosekunden die vom Ursprung angenommene maximale Abweichung zwischen Synchronisierungsintervallen. Bei isSynced="0" darf das Feld nicht erscheinen. Die Spezifikation empfiehlt, es nur zu senden, wenn der Ursprung die Zuverlässigkeit seiner Zeitquelle tatsächlich kennt. Diese Kenntnis entstammt laut Anhang in der Regel der Betreiberkonfiguration; zugleich warnt die RFC vor einem falschen Eindruck von Genauigkeit.

Die Spezifikation regelt außerdem den Fall, dass isSynced="1" vorhanden ist, aber syncAccuracy fehlt: Ein Collector oder Relay darf dann annehmen, dass die Zeit genau genug ist, um als korrekt zu gelten. Das ist eine Regel für die Interpretation durch die Empfangsseite. Sie macht aus dem Senderfeld keine Telemetrie über den Zeitserver.

Von der Quelle bis ins Archiv

Im IANA-Register sind timeQuality, tzKnown, isSynced und syncAccuracy als optionale Parameter aufgeführt. Empfangssysteme müssen daher auch Nachrichten ohne diese Angaben verarbeiten. Ihr Fehlen beweist nicht, dass die Uhr falsch ging; es lässt jedoch weniger expliziten Kontext für die Beurteilung zurück.

Das Risiko entsteht, wenn eine Pipeline die Uhrzeit normalisiert und den strukturierten Kontext verwirft. Ein späterer Analyst sieht dann einen Zeitstempel mit Sekundenbruchteilen, aber nicht mehr die Einschränkung, die der Sender mitgeliefert hatte. Das Element sollte zusammen mit dem Zeitwert erhalten bleiben. Zusätzlich muss die Verbindung zur ursprünglichen Maschine, zum Konfigurationsverantwortlichen und zur zeitbezogenen Überwachung auffindbar sein.

RFC 8633 empfiehlt, Zeitquellen und NTP-Instanzen zu überwachen sowie nicht synchronisierte Server zu erkennen. Diese Betriebspraxis kann eine Senderangabe stützen. Sie belegt nicht, wie ein konkreter Betreiber arbeitet. Die ausgewerteten Quellen liefern auch keine Zahlen zu Verbreitung oder tatsächlichen Fehlerquoten.

Die Qualität wird nicht im Paket verifiziert

timeQuality dokumentiert, welchen Zeitstatus der Ursprung meldet. Das hilft Empfängern, den Grad der Unterstützung für einen Zeitstempel zu unterscheiden und Unsicherheit bei einer Rekonstruktion sichtbar zu lassen. Es authentifiziert weder das Ereignis noch beweist es allein eine kausale Reihenfolge zwischen Maschinen oder die Wahrheit des gemeldeten Zustands.

Heng Lus Gedanke der Running-Code Primacy dient hier nur als redaktioneller Blickwinkel: Eine geschriebene Kennzeichnung ersetzt nicht, was ein laufendes System prüft und tatsächlich ausführt. Die RFC definiert die Form der Mitteilung. Ihre Grundlage bleibt die Konfiguration und Überwachung der sendenden Maschine. Der Collector kann diese Grenze bewahren; nachträglich kann er die fehlende Betriebsgrundlage nicht herstellen.

Quellen