Worum geht’s
Dein selbstgehosteter Dienst antwortet nicht mehr — Nutzer melden Fehler 500. In diesem Capstone führst du eine echte Root-Cause-Analyse durch: vom Symptom über die Logs zur Ursache, mit Querblick auf Monitoring und Storage. Du nutzt alles aus Pfad D zusammen: systematisch messen statt raten, korrelieren statt vermuten, beheben und verifizieren.
Konzept
Eine belastbare Störungsbehebung folgt immer derselben Schleife:
- Symptom erfassen — was sehen Nutzer, seit wann, wie reproduzierbar?
- Messen vor ändern — Status der Dienste (
systemctl/docker ps), Monitoring-Dashboard, dann erste Fehlerzeile im Log in der Zeit. - Korrelieren — Zeitstempel über Dienste hinweg verfolgen, Vorboten (WARN) beachten, an Storage/Ressourcen denken (Volume voll? RAID degraded?).
- Hypothese → Fix → Verifikation — eine Ursache annehmen, gezielt korrigieren, dann belegen, dass Symptom und Fehlerzeilen verschwunden sind.
- Nachsorge — Alarm/Check ergänzen, damit derselbe Ausfall früher auffällt; Vorfall dokumentieren (Runbook).
Die häufigste Falle: am Symptom (500) herumdoktern, statt der Kausalkette zur echten Ursache zu folgen.
Beispiel-Fall
Gegeben: Container-App liefert 500. Monitoring zeigt seit 08:02 „Service down”. So arbeitest du es ab:
docker ps→webläuft,dbläuft. Also kein abgestürzter Container.- Log-Station:
docker logs web→ erste ERROR-Zeile 08:02:03connection to postgres refused. Symptom = 500, mutmaßliche Ursache = keine DB-Verbindung. - Korrelieren:
docker logs dbum 08:02 →FATAL: No space left on device. - Storage-Station:
df -h→ das DB-Volume ist zu 100 % voll. Root Cause gefunden. - Fix + Verifikation: Alte Backups/Logs aufräumen oder Volume vergrößern, DB
neu starten →
GET /api/usersliefert wieder 200, Monitoring wechselt auf „up”. - Nachsorge: Disk-Usage-Alarm bei 85 % einrichten (vgl. D4), Cleanup-Cronjob planen (vgl. D6).
Anwenden
Arbeite die drei Tool-Stationen in Reihenfolge ab — sie spiegeln die echte RCA-Schleife wider:
Station 1: Die erste Fehlerzeile zeigt die Richtung — folge ihr, nicht dem lautesten Eintrag.
- Station 1 — Logs: Füge ein Log mit ERROR ein, filtere auf ERROR und finde die erste Fehlerzeile in der Zeit.
- Benenne Symptom und mutmaßliche Ursache aus der Zeile davor.
- Notiere den Zeitstempel, um an den anderen Stationen zu korrelieren.
Station 2: Übersetze die Ausfalldauer in verbrauchtes SLA-Budget — das begründet die Nachsorge-Maßnahmen.
- Station 2 — Monitoring/SLA: Bestimme, wie viel Ausfallbudget der Vorfall verbraucht hat.
- Lies das Monatsbudget deiner Verfügbarkeitsklasse ab und vergleiche mit der Ausfalldauer.
- Leite ab, ob ein zusätzlicher Check/Alarm das Budget künftig schützt.
Station 3: Stelle sicher, dass die Storage-Auslegung samt Frühwarnung den Wiederholungsfall verhindert.
- Station 3 — Storage: Prüfe, ob die Kapazitätsplanung den Vorfall (volles Volume) hätte verhindern können.
- Rechne durch, wie viel nutzbarer Speicher bei deinem RAID-Level zur Verfügung steht.
- Leite eine Kapazitäts-/Monitoring-Maßnahme ab (z. B. Disk-Alarm + größeres Volume).
Selbsttest
Zunächst der geführte Entscheidungsbaum durch den Vorfall:
Praxis-Challenge
Spiele den Vorfall durch: Erzeuge (oder nimm) ein Log mit einer „connection refused”-Fehlerkette, finde im Log-Viewer die erste Fehlerzeile, korreliere zur mutmaßlichen Ursache und schreibe ein kurzes Runbook in fünf Schritten (Symptom → Messung → Korrelation → Fix → Nachsorge). Bestimme im SLA-Rechner, wie viel Ausfallbudget der Vorfall gekostet hätte, und im Storage-Rechner eine Kapazitätsmaßnahme, die den vollen-Volume-Fall künftig verhindert.