Log-Analyse & Root-Cause

Worum geht’s

Wenn ein Dienst spinnt, steht die Wahrheit im Log — wenn du sie liest. Im Second-Level filterst du tausende Zeilen auf das Wesentliche, erkennst die Severity, korrelierst Ereignisse über mehrere Dienste hinweg und arbeitest dich von der ersten Fehlermeldung zur eigentlichen Ursache (Root Cause) vor.

Konzept

• Logformate: Docker-JSON, NDJSON, nginx-Access, syslog, Plaintext. Jedes hat Zeitstempel, oft eine Severity und eine Nachricht. Beim Lesen normalisierst du im Kopf auf „wann · wie schwer · was”.
• Severity-Stufen (von schwer nach leicht): ERROR/FATAL (etwas ist kaputt), WARN (Vorzeichen / degradiert), INFO (normaler Betrieb), DEBUG (Details fürs Entwickeln). Beim Troubleshooting zuerst auf ERROR filtern, dann den Kontext drumherum lesen.
• Korrelation: Ein Fehler hat oft einen Vorboten weiter oben. WARN cache miss → ERROR db connection refused → ERROR request failed 500 ist eine Kausalkette, keine drei zufälligen Zeilen. Der Zeitstempel verbindet Ereignisse über mehrere Dienste/Container.
• Root Cause vs. Symptom: Das 500 ist das Symptom, die abgelehnte DB-Verbindung die wahrscheinliche Ursache, ein voll gelaufenes Volume oder ein abgestürzter DB-Container die eigentliche Ursache dahinter. Frage so lange „warum?“, bis du an der ersten Domino-Stein bist.

Die erste ERROR-Zeile in der Zeit ist meist näher an der Ursache als die lauteste oder letzte.

Konzept-Visualizer

Filtere nach Severity und durchsuche die Beispiel-Logs. Filtere auf ERROR und lies dann die WARN-Zeile direkt davor — dort liegt oft der Auslöser.

Beispiel-Fall

Gegeben: Eine App liefert plötzlich Fehler 500. Im Log stehen (gekürzt):

08:01:20 INFO  GET /api/users 200 12ms
08:01:50 WARN  cache miss for key user:42, fetching from DB
08:02:03 ERROR connection to postgres refused (host=db:5432)
08:02:04 ERROR request failed: GET /api/users 500

1. Auf ERROR filtern → zwei Zeilen um 08:02. Das 500 ist das, was der Nutzer sieht — das Symptom.
2. Zeitlich davor lesen: 08:02:03 connection to postgres refused. Die App bekommt keine DB-Verbindung — wahrscheinliche Ursache des 500.
3. Korrelieren: Im DB-Container nachsehen (docker logs db um 08:02). Dort z. B. FATAL: could not write to file … No space left on device.
4. Root Cause: Das DB-Volume ist voll → DB nimmt keine Verbindungen mehr an → App-Anfragen scheitern → 500 beim Nutzer.
5. Beheben & verifizieren: Platz schaffen / Volume vergrößern, DB neu starten, dann GET /api/users → wieder 200. Log zeigt keine neuen ERROR.

Lehre: Symptom → erste Fehlerzeile → korreliertem Dienst folgen → echte Ursache. Nicht beim ersten ERROR stehenbleiben.

Anwenden

Selbsttest

Praxis-Challenge