Viele Unternehmen sind in unserer globalisierten Welt und vielen Standorten auf verschiedenen Kontinenten vertreten, die Uhren mit den aktuellen Zeiten könnten also so aussehen:

Sehen wir uns ein paar Fakten zum Thema Zeitzonen allgemein an:

• Es gibt verschiedene Zeitzonen in Regionen wie AMER, EMEA, APAC, verschiedene Zeitzonen in den Ländern
  • 4 Haupt-Zeitzonen in den USA – EST, CST, MST, PST
  • 11 Zeitzonen in Russland
  • 12 Zeitzonen in Frankreich — Weltrekord!
• Zeitzonen mit 30 Minuten Verschiebung wie Indien
• Zeitzonen mit oder ohne Sommerzeit, Sommerzeitumstellung an verschiedenen Tagen(New York: 08-MAR-2020 bis 01-NOV-2020, London 29-MAR-2020 bis 25-OKT-2020)

Wir sehen also, dass das Thema Zeitzonen an sich schon recht kompliziert ist, auch ganz ohne IT oder Splunk.
Das folgende Bild gibt den Inhalt eines Dialogs aus einem anderen PS-Projekt wieder, welches ein Fachverantwortlicher Manager irgendwo am Rhein mit einem Splunk-Administrator in Malaysia führte, und der den Umsatz des Konzerns vom Vortag in Thailand erfragen wollte:

Die einfache erscheinende Frage nach dem gestrigen Umsatz wird schon recht kompliziert, wenn drei verschiedene Zeitzonen beteiligt sind: meinen wir „gestern“ in Deutschland, in Thailand oder Malaysia?
Manche IT-Administratoren machen sich das Leben leicht und definierten ihre Welt ausschließlich in UTC, das bedeutet konkret, sie stellen alle Server auf UTC-Zeit ein, unabhängig vom tatsächlichen Standort:

Dieser Ansatz ist einigermaßen pragmatisch, ist aber vermutlich nur aus der Sichtweise der Server-Administratoren eine Lösung, wenn man überwiegend mit tail -f auf die Logs des eigenen Server schaut. Die folgenden Aspekte sollte man bedenken, bevor man alle Server auf UTC umstellt:

• Dieser Ansatz erzeugt gezielt falsche Log-Einträge, was u.a. gegen die Richtlinien vieler Unternehmen zur ordnungsgemäßen Protokollierung von Vorgängen in IT-Systemen verstoßen dürfte. Es ist sicher nicht leicht, einem Auditor zu erklären, dass er die Logs nur verstehen kann, wenn er im Kopf 7 bis 8 Stunden dazurechnen muss und dabei auch die unterschiedlichen Termine der Sommerzeitumstellung berücksichtigen muss.
• Nicht alle IT-Systeme können auf UTC eingestellt werden, da gibt es deutliche Hürden jenseits der „normalen“ Server-Welt:
  • Möchte der Vorstandsvorsitzende sein Notebook in UTC betreiben?
  • Was ist mit medizinischen Geräten oder IoT-Geräten allgemein?
  • Was machen wir mit IT-Systemen die durch externe Firmen betrieben werden?

Unter dem Strich ist es in den meisten Fällen eine schlechte Idee, die komplexe Thematik der globalen Zeitzonen mi einfachen Antworten wie „alles auf UTC“ zu bekämpfen.

Zeitstempel und Zeitzonen in Splunk

Schauen wir uns an, wie Splunk mit diesem Thema umgeht. Dazu blicken wir zunächst auf den Prozess der Verarbeitung der Daten in Splunk. In der Parsing-Phase wird der ankommende Datenstrom zuerst in einzelne Events zerlegt (Line Breaking), danach wird für jedes Event der Zeitstempel mit der entsprechenden Zeitzone bestimmt.
Die Zeitstempelerkennung läuft grob nach den folgenden Regeln ab:

1. Im Event wurde ein Zeitstempel mit Zeit UND Datum gefunden
   1. Verwende die Regeln, in props.conf definiert sind für host, source, sourcetype (Reihenfolge beachten)
   2. Verwende die Standard-Werte für TIME_PREFIX, MAX_TIMESTAMP_LOOKAHEAD, TIME_FORMAT
2. Im Event wurde ein Zeitstempel mit Zeit aber OHNE Datum gefunden
   1. Verwende die Zeit aus dem Event und das Datum aus dem Namen der Log-Datei
   2. Verwende die Zeit aus dem Event und das Datum, an dem die Log-Datei geändert wurde (modtime)
3. Im Event wurde kein Zeitstempel gefunden
   1. Verwende die Zeit aus dem vorherigen Event mii dem gleichen Werte in source
   2. Verwende die Zeit des Forwarders
   3. Verwende die Zeit des Indexers
4. Speichere den Zeitstempel als epoch / Unix Format mit Millisekunden (wenn verfügbar), also normalisiert auf UTC

Die Zeitzone wird dabei so ermittelt:

1. Verwende die Zeitzone des Events (z.B. PST, -0800) wie in folgendem Beispiel:

2. Verwende das Attribut TZ in props.conf, wenn das Event den passenden Wert für host, source, oder sourcetype hat. In folgendem Beispiel setzen wir die Zeitzone für alle Hosts die mit „sf“ beginnen (San Francisco) auf PST für Pacific Standard Time, und für alle Hosts die mit „ny“ (New York) beginnen auf EST für Eastern Standard Time.

3. Verwende die Zeitzone des Forwarders (Splunk Version 6.x)
4. Verwende die Zeitzone des Servers, der das Event parst

Betrachten wir ein Beispiel mit 3 Servern in New York/USA, Frankfurt/Deutschland und New Delhi/Indien.

Alle 3 Server sind auf die lokale Zeitzone eingestellt und schreiben zum gleichen Zeitpunkt (14:00 in Frankfurt) jeweils eine Log-Zeile mit der lokalen Zeit in unsere Test-Logdatei:

Ohne spezielle Konfiguration laden wir die Test-Logdatei in Splunk, die Standard-Einstellungen erkennen sowohl Zeitstempel wie auch die Zeitzone korrekt — die Zeitzone ist ja in dem Beispiel im Log-Eintrag vorhanden. In der Suche index=main zeigt jedes Event den unveränderten Zeitstempel wie in der Test-Logdatei, für New Delhi also 17:30, für Frankfurt 14:00 und für New York 8:00. In der Spalte „Time“ steht bei allen die gleiche Zeit, die lokale Zeit in Frankfurt zu dem Zeitpunkt, als die Events geschrieben wurden (14:00).

Mit einer leicht geänderten Suche können wir die intern von Splunk gespeicherte Zeit anzeigen, die epoch oder Unix Zeit, die bei allen Events gleich ist:

Die Splunk GUI zeigt das interne Feld _time nicht als 10- bzw. 13-stellige epoch-Zeit an, sondern in der menschen-lesbaren Format. Das mit eval erzeugte Feld mytime zeigt hingegen die interne epoch-Darstellung:

Warum wird in der GUI das Feld _time jetzt genau als 14:00 angezeigt? Das liegt an der Einstellung der Zeitzone im Benutzerprofil. Für den Benutzer ist hier aktuell die Zeitzone „Berlin“ eingestellt:

Darum wird die epoch-Zeit 1588507200 als 2 Uhr nachmittags am 3. Mai 2020 für die Zeitzone GMT+02:00 angezeigt, wie wir z.B. hier überprüfen können.

Wenn wir eine andere Zeitzone im Benutzerprofil wählen, z.B. New Dehli in Indien, dann werden die gleichen Events mit einer anderen zeit angezeigt:

Nachdem wir nun wissen, wie die Zeitstempel der Events sowohl intern als auch bei der Anzeige in SplunkWeb verarbeitet werden, schauen wir uns die zeitlichen Grenzen einer Suche an. Jede Suche von Splunk verwendet zwei Werte, um den Suchzeitraum einzugrenzen:

• earliest: Der Beginn des Suchzeitraums, muss immer angegeben werden
• latest: Das Ende des Suchzeitraums, wenn nicht angegeben wird „jetzt“ verwendet

Die vom Benutzer gewählten Werte für earliest und latest werden intern wieder in epoch-Zeiten umgewandelt. Diese Darstellung finden wir z.B. im Job Inspector > Search job properties > searchEarliestTime & searchLatestTime:

Zum Testen führen wir eine beliebige Suche mit zwei unterschiedlichen Zeitzonen im Benutzerprofil über „Last 24 Hours“ aus und vergleichen die im Job Inspector gefunden Werte:

• searchEarliestTime bei beiden Suchen gleich
• searchLatestTime minimal unterschiedlich (bedingt durch den Wechsel der Profileinstellungen)

In diesem Fall macht es also keinen Unterschied, welche Zeitzone wir im Benutzerprofil wählen, der auf UTC normalisierte Suchzeitraum ist der gleiche. Wie sieht es aber aus bei anderen Suchzeiträumen? Dazu führen wir wieder eine Suche mit zwei unterschiedlichen Zeitzonen im Benutzerprofil, diesmal aber über „Yesterday“ aus:

• Sowohl searchEarliestTime als auch searchLatestTime sind nun deutlich anders
• Die Differenz zwischen searchLatestTime und searchEarliestTime ist exakt 86400 (1 Tag), da bildet also den Zeitraum „Yesterday“ korrekt ab
• Die Differenz von searchEarliestTime zwischen den beiden Suchen beträgt 12600 Sekunden (3,5 Stunden), was genau der unterschiedlichen Verschiebung der Zeitzonen Berlin und New Dehli entspricht.

Zusammenfassung:

• Splunk verwendet zum Speichern der Zeitstempel der Events intern das auf UTC normalisierte epoch-Format
• Auch für die Suchen verwendet Splunk intern das epoch-Format
• Zur Anzeige der Zeitstempel in des GUI verwendet Splunk eine menschen-lesbare Darstellung der epoch-Zeiten, welche an die im Benutzerprofil gewählte Zeitzone angepasst werden
• Beim Speichern von zeitgesteuerten Suchen oder Alarmen verwendet Splunk die im Benutzerprofil gewählte Zeitzone, um den Zeitpunkt für die Ausführung der Suche sowie das Suchzeitfenster zu bestimmen
• Bei Suchen mit festen Stunden- bzw. Tages-Grenzen immer prüfen, ob tatsächlich die gewünschten Zeiten verwendet werden

Im nächsten Artikel aus dieser Reihe werden wir uns dann anschauen, wie wir Splunk in verschiedenen Szenarien so konfigurieren, dass beim Einlesen der Daten auch immer die richtige Zeitzone erkannt wird.

Übrigens bieten wir auch Jobs an. Mehr erfährst du hier.