Modul 10: Observability — Systeme verstehen, die man nicht anfassen kann

Von Monitoring zu Observability

Monitoring beantwortet bekannte Fragen: Läuft der Server? Ist die CPU hoch? Observability beantwortet unbekannte Fragen: Warum ist die Checkout-Latenz um 14 Uhr gestiegen? Der Unterschied liegt in den Daten: Monitoring sammelt vordefinierte Metriken, Observability sammelt Kontext — genug, um neue Fragen zu stellen.

Lesson 1: Die drei Säulen

Metrics (Zahlen über Zeit: Requests/sec, Latenz p99, Fehlerrate — billig, aggregierbar). Logs (Ereignisse mit Kontext: Zeilen mit Timestamp, Level, Trace-Id — teuer, detailreich). Traces (Anfrage-Pfad über Services: Span-Tree mit Timings — teuer, verbindet). Zusammen ergeben sie das volle Bild: Die Metrik zeigt "Latenz hoch", der Trace zeigt "welcher Service", das Log zeigt "warum".

Lesson 2: Structured Logging

Loggt strukturiert (JSON), nicht Klartext — jede Zeile ein JSON-Objekt mit Timestamp, Level, TraceId, UserId, Message und Feldern. Strukturierte Logs sind maschinenabfragbar (grep, jq, Log-Query-Sprache). Log-Level sparsam: ERROR (menschliche Aufmerksamkeit nötig), WARN (verdächtig, aber lauffähig), INFO (Geschäftsereignisse), DEBUG (nur Entwicklung). Niemals Secrets oder personenbezogene Daten loggen (DSGVO).

{"ts":"2026-03-20T14:02:11Z","level":"WARN","service":"policy",
 "traceId":"4bf92f3577b34da6","userId":"u-8123",
 "event":"payment_timeout","policyId":"P-2091","attempt":2}

Mit TraceId lassen sich alle Zeilen einer Anfrage über alle Services hinweg verketten — das ist die Brücke zu Tracing.

Lesson 3: Distributed Tracing

Ein Trace folgt einer Anfrage über alle Services: Gateway, Order, Payment, Notification. Jede Station ist ein Span mit Start, Dauer, Tags, Trace-Id. Die Trace-Id wandert über Header (W3C Trace Context). Instrumentierung: Micrometer Tracing oder OpenTelemetry, Spring Boot macht vieles automatisch. Span-Attribute (user.id, order.value) machen Traces abfragbar: "Zeige alle Traces mit order.value über 1000 und Latenz über 2s".

Lesson 4: RED und USE — was messen?

RED für Services: Rate (Requests/sec), Errors (Fehlerrate), Duration (Latenz, p50/p95/p99). USE für Ressourcen: Utilization (Auslastung), Saturation (Warteschlange), Errors (Hardware-/Treiberfehler). Die vier Golden Signals (Google): Latency, Traffic, Errors, Saturation. Faustregel: Jeder Service hat RED-Metriken, jede Ressource USE-Metriken, Dashboards zeigen die Golden Signals pro SLO.

Lesson 5: Alerting und SLOs

Alerts ohne Aktion sind Rauschen. Jeder Alert braucht einen Besitzer und einen Runbook-Eintrag. SLOs machen Ziele messbar: "99.9% der Requests in unter 300ms" — daraus folgt ein Error Budget (0.1% = 43 Min/Monat), das verausgabt werden darf. Page-Alerts (rufen nachts jemanden) nur für nutzerwirksame Ausfälle; alles andere geht in ein Ticket. Burn-Rate-Alerts ("Error Budget brennt 14x schneller als geplant") sind aussagekräftiger als absolute Schwellwerte.