Monitoring & Observability: Volle Transparenz im Betrieb

Monitoring und Observability sind eng verwandt, aber nicht identisch. Monitoring beantwortet vor allem „Ist das System gesund?“ – Observability ermöglicht, unbekannte Probleme schnell zu verstehen: „Warum verhält sich das System so?“

Beides ist für zuverlässigen IT‑Betrieb entscheidend: Ohne Monitoring merken Sie Störungen zu spät. Ohne Observability dauern Ursachenanalyse und Wiederherstellung zu lange – und Incidents werden teuer.

Monitoring vs. Observability: die praktische Abgrenzung

Monitoring

Monitoring überwacht bekannte Signale und löst Alerts aus, z. B.:

• Verfügbarkeit (Up/Down)

• Fehlerrate und Latenz

• Kapazität/Saturation (CPU, Memory, Queue‑Backlog)

Es eignet sich gut für wiederkehrende, bekannte Failure‑Modes.

Observability

Observability bedeutet, dass Sie ein System über seine Signale so gut „beobachten“ können, dass auch neue, unerwartete Fehlerbilder debugbar sind. Dafür brauchen Sie:

• konsistente Korrelations‑IDs,

• strukturierte Logs,

• Tracing über Service‑Grenzen,

• sinnvolle Dimensionen/Labels in Metriken.

Die drei Säulen: Metriken, Logs, Traces (und wie sie zusammenarbeiten)

Metriken: schnell, aggregiert, steuerbar

Metriken zeigen Trends und Anomalien effizient:

• Latenz (p95/p99), Fehlerraten, Throughput

• Queue‑Längen, Worker‑Sättigung, Cache‑Hit‑Rate

• Ressourcenverbrauch als Kontext, nicht als Hauptziel

Für Web‑Services sind RED‑Signale (Rate, Errors, Duration) oft ausreichend als Einstieg.

Logs: Kontext und Details

Logs sind dann wertvoll, wenn sie strukturiert sind (JSON) und nicht als „Textmüll“ enden. Gute Logs enthalten:

• Timestamp, Level, Service, Environment

• Request‑ID/Trace‑ID, Benutzer-/Tenant‑Kontext (wo zulässig)

• Fehlercodes und klaren Message‑Text

Wichtig ist eine Retention‑Strategie (Kosten vs. Nutzen) und ein Zugriffskonzept (Sicherheit/Compliance).

Traces: der Weg eines Requests

Traces verbinden Services miteinander: Wo entsteht Latenz? Welche Abhängigkeit ist langsam? Welche Retries laufen? Tracing ist besonders hilfreich bei:

• Microservices/Service‑Meshes,

• komplexen API‑Ketten,

• „sporadischen“ Performance‑Problemen.

Instrumentierung standardisiert OpenTelemetry:

• OpenTelemetry: https://opentelemetry.io/

Alerting: Signalqualität vor Alarmmenge

Das häufigste Observability‑Problem ist nicht „zu wenig Daten“, sondern zu viele schlechte Alerts. Alert Fatigue führt dazu, dass Teams Alerts ignorieren – und dann im Ernstfall überrascht werden.

SLO‑basiertes Alerting statt „CPU > 80%“

SLOs helfen, Alerts an Nutzerimpact zu koppeln:

• „Fehlerrate über Schwelle“ oder „Latenz p95 über Ziel“

• Error Budget Burn Rate (z. B. „Budget in 1h verbraucht“)

Weiterführend:

• SLA, SLO & Incident Response

Actionable Alerts: jeder Alert braucht eine Handlung

Eine einfache Regel: Wenn niemand sagen kann, was beim Alert zu tun ist, gehört er nicht in Paging. Dafür helfen:

• klare Severity‑Stufen,

• Deduplizierung/Grouping,

• Silence‑Mechanismen,

• Runbooks pro kritischem Alert.

Runbooks und Dokumentation sind Teil des Systems:

• Dokumentation & Runbooks

Tool‑Stack: ein praxistaugliches Open‑Source Setup

Viele Teams fahren gut mit einem integrierten Metrics‑Logs‑Traces‑Stack:

• Prometheus: https://prometheus.io/docs/

• Grafana: https://grafana.com/docs/

• Loki (Logs): https://grafana.com/oss/loki/

• Tempo (Traces): https://grafana.com/oss/tempo/

• Alertmanager: https://prometheus.io/docs/alerting/latest/alertmanager/

Entscheidend ist weniger der Hersteller als Konsistenz: gemeinsame Labels, einheitliche Dashboards, klare Ownership.

Betriebspraxis: Dashboards, On‑Call und Incident‑Fähigkeit

Dashboards, die helfen (statt „NOC‑Wallpaper“)

Bewährt hat sich ein mehrstufiges Dashboard‑Modell:

• Service Overview (SLO/RED, wichtigste Abhängigkeiten)

• Drill‑down (DB/Queue/Cache, Ressourcensignale)

• Debug‑Ansicht (Top Errors, Slow Endpoints, Trace‑Links, Log‑Queries)

Verbindung zu Wartung und Change‑Prozessen

Observability liefert auch Signale für Wartung:

• abnehmende Performance nach Updates,

• steigende Fehler nach Changes,

• Kapazitätsplanung.

Weiterführend:

• Wartung & Patch Management

• CI/CD-Pipeline-Aufbau

Datenmodell: Labels, Kardinalität und Retention (damit es bezahlbar bleibt)

Observability scheitert häufig an Details: zu viele Labels, zu hohe Kardinalität, zu lange Aufbewahrung – oder umgekehrt: zu kurze Retention, sodass die Ursachenanalyse nach dem Incident nicht mehr möglich ist.

Pragmatische Leitplanken:

• Labels sparsam, aber konsistent: service, env, region, status_code sind meist sinnvoll. Vermeiden Sie hochvariable Labels wie user_id, request_id oder unbounded URLs.

• Kardinalität aktiv steuern: Hohe Kardinalität treibt Speicher und Query‑Kosten. Für Debugging sind Logs/Traces oft besser geeignet als „alles als Metrik“.

• Retention nach Signaltyp: Metriken länger (z. B. 30–180 Tage), Logs selektiv (z. B. Errors länger, Info kürzer), Traces oft kürzer oder gesampelt (abhängig von Bedarf und Kosten).

• Sampling bewusst wählen: Head‑/Tail‑Sampling (Tracing) kann helfen, wichtige Fälle zu behalten, ohne Volumen zu sprengen.

Mit einem klaren Datenmodell werden Dashboards schneller, Alerts stabiler und das System bleibt langfristig betreibbar.

FAQ

Wie startet man mit SLOs, ohne ein „SLO-Projekt“ zu machen?

Beginnen Sie mit 1–3 kritischen Services und definieren Sie je Service einen SLI für Erfolg und einen für Latenz. Nutzen Sie diese Signale für Alerts und Review‑Routinen – und erweitern Sie erst dann.

Welche Retention ist sinnvoll?

Als grobe Faustregel: Metriken länger, Logs selektiv nach Wert (Errors länger), Traces kürzer oder gesampelt. Entscheidend ist, dass Sie mindestens einen Incident‑Zeitraum plus Vergleichsfenster abdecken.

Metriken oder Logs – was ist wichtiger?

Metriken sind ideal für Trends und Alerting, Logs für Kontext. In der Praxis brauchen Sie beides – plus Tracing, wenn Systeme verteilt sind.

Quick Wins: in 2–4 Wochen spürbar besser

• SLOs für die kritischsten 1–3 Services definieren und daran Alerts ausrichten

• Request/Trace‑IDs durchgängig machen (API Gateway → Services → Logs)

• strukturierte Logs einführen (mind. für Errors und kritische Flows)

• „Top‑10 Alerts“ reviewen und entstressen (actionable machen oder löschen)

• Runbooks für die häufigsten Incidents schreiben und verlinken

Fazit

Monitoring und Observability reduzieren Downtime nicht durch „mehr Tools“, sondern durch bessere Signale und schnellere Ursachenanalyse. Mit SLO‑basierter Alarmierung, korrelierbaren Metriken/Logs/Traces und gelebten Runbooks wird Betrieb planbarer – und Änderungen werden sicherer, weil Probleme früh sichtbar werden.