Logs auswerten

Worum geht’s

Wenn ein Dienst klemmt, steht die Antwort fast immer in den Logs. Vom Ticket im First-Level bis zur Root-Cause-Analyse im Second-Level ist das Lesen, Filtern und Korrelieren von Log-Zeilen die zentrale Diagnose-Fähigkeit. Wer Severities unterscheidet und Zeitstempel korreliert, findet die Ursache, statt im Rauschen zu ertrinken.

Konzept

• Severity-Stufen (Syslog-Ordnung, hoch → niedrig): EMERG, ALERT, CRIT, ERROR, WARN, NOTICE, INFO, DEBUG. Bei der Fehlersuche zuerst auf ERROR und höher filtern — das ist das Signal, der Rest oft Rauschen.
• Formate: Logs kommen als Docker JSON, NDJSON (eine JSON-Zeile pro Eintrag), nginx-Accesslog, syslog oder als unstrukturierter Plain-Text. Das Format bestimmt, wie man Zeitstempel und Level herausliest.
• Zeitstempel korrelieren: Den ersten Fehler suchen, nicht den lautesten. Folgefehler haben spätere Zeitstempel; die eigentliche Ursache liegt oft eine Zeile davor — beim Übergang von „läuft” zu „kaputt”.
• WARN ≠ ERROR: Eine Warnung ist ein Hinweis, kein Ausfall. Nicht jede Warnung ist die Ursache eines Tickets — erst die Eskalation zu ERROR zählt.

Vorgehen: Format erkennen → auf ERROR+ filtern → ältesten Fehler finden → Kontextzeilen drumherum lesen → Hypothese bilden.

Severity-Filter und Suche trennen Signal von Rauschen:

Beispiel-Fall

Gegeben: Eine Web-App liefert 502. Im Log (Auszug, sortiert nach Zeit):

12:01:03 INFO  started worker pid=42
12:04:11 WARN  upstream slow: 1800ms
12:04:12 ERROR connect to db:5432 failed: timeout
12:04:12 ERROR request failed -> 502

1. Auf ERROR filtern → zwei Treffer, beide um 12:04:12.
2. Ältesten Fehler nehmen: connect to db:5432 failed: timeout.
3. Der 502 ist die Folge, nicht die Ursache — die DB war nicht erreichbar.
4. Die WARN-Zeile davor (upstream slow) ist ein Frühindikator, kein Auslöser.

Lehre: Der sichtbare Fehler (502) ist selten die Wurzel. Filtern auf ERROR und den ältesten Eintrag nehmen führt zur eigentlichen Ursache (DB-Timeout).

Anwenden

Selbsttest

Praxis-Challenge