Das Wichtigste in Kürze
- Monitoring beantwortet bekannte Fragen (Ist der Server up?). Observability beantwortet unbekannte Fragen (Warum ist die API langsam?)
- Die drei Säulen: Logs (Was ist passiert?), Metriken (Wie viel?), Traces (Wo im System?)
- OpenTelemetry (OTel) wird zum De-facto-Standard für Instrumentierung — vendor-neutral und CNCF-backed
- Kosten-Explosion bei Observability: 30-50 Prozent der Cloud-Rechnung fließen in Logging und Monitoring bei manchen Unternehmen
- Der Trend geht zu Observability-as-Code: Dashboards, Alerts und SLOs versioniert im Git-Repo
Monitoring reicht nicht mehr. In verteilten Cloud-Systemen mit Hunderten Microservices ist die Frage nicht „Ist der Server online?“, sondern „Warum dauert dieser eine API-Call 3 Sekunden statt 200 Millisekunden?“. Observability liefert die Antwort — durch die Korrelation von Logs, Metriken und Traces. Doch die Disziplin hat ihre eigenen Herausforderungen: Kosten, Komplexität und Tool-Sprawl.
Der Paradigmenwechsel: Von Dashboards zu Exploration
Klassisches Monitoring basiert auf vorab definierten Checks und Dashboards: CPU-Auslastung, Disk-Usage, HTTP-Status-Codes. Das funktioniert für bekannte Failure Modes. Aber in verteilten Systemen sind die meisten Probleme unbekannt: Ein Request durchläuft 15 Services, und die Latenz steigt — welcher Service ist schuld?
Observability dreht das Modell um: Statt vorab zu definieren, was überwacht wird, werden alle relevanten Daten gesammelt und retrospektiv abgefragt. Das System ist „observable“, wenn man aus den externen Outputs (Logs, Metriken, Traces) den internen Zustand rekonstruieren kann.
Die drei Säulen — und ihre Verbindung
Logs erzählen, was passiert ist — in natürlicher Sprache. „User 42 hat Login fehlgeschlagen, Grund: invalid_password“. Metriken quantifizieren: „Login-Fehlerrate: 5,3 Prozent in den letzten 5 Minuten“. Traces zeigen den Weg: „Request X hat 15 Services durchlaufen, 80% der Latenz entstand in Service Y“.
Der Wert entsteht durch die Verbindung: Ein Alert auf einer Metrik (Fehlerrate > 5%) führt zu einem Trace (welcher Request?), der zu einem Log führt (was genau ist fehlgeschlagen?). Ohne diese Korrelation bleibt jede Säule isoliert — und das Debugging dauert Stunden statt Minuten.
OpenTelemetry: Das Ende des Vendor Lock-in
OpenTelemetry (OTel) ist das CNCF-Projekt, das die Instrumentierung standardisiert. Statt jeder Observability-Plattform (Datadog, New Relic, Dynatrace, Grafana) eine eigene SDK unterzuschieben, definiert OTel ein einheitliches Format für Logs, Metriken und Traces.
Der strategische Vorteil: Einmal instrumentieren, an jeden Backend schicken. Wechsel von Datadog zu Grafana? Kein Code-Umbau — nur die Exporter-Konfiguration ändern. OTel reduziert den Vendor Lock-in in einem Markt, der notorisch proprietär ist.
Die Kostenfalle: Wenn Observability teurer wird als die Anwendung
Datadog-Rechnungen im sechsstelligen Bereich sind keine Seltenheit. Die Kosten skalieren mit dem Datenvolumen — und moderne Anwendungen produzieren enorme Mengen an Telemetrie-Daten. Ohne Sampling-Strategie und Retention-Policies wird Observability zum Kostentreiber.
Gegenmaßnahmen: Head-based oder Tail-based Sampling (nicht jeden Trace speichern, nur interessante), Log-Level-Management (Debug-Logs nur bei Bedarf), Metriken-Aggregation (Sekunden- statt Millisekunden-Granularität) und Open-Source-Backends (Grafana + Loki + Tempo + Mimir als Alternative zu SaaS-Plattformen).
Häufige Fragen
Brauche ich alle drei Säulen?
Für einfache Systeme (Monolith, wenige Services) reichen Metriken und Logs. Sobald verteilte Systeme mit 5+ Services im Spiel sind, werden Traces essenziell — sie zeigen, wo im System die Latenz entsteht. Die vollständige Korrelation aller drei Säulen spart im Incident-Fall Stunden.
Was kostet Observability?
SaaS-Plattformen: 15-25 EUR/Host/Monat für Infrastruktur-Monitoring, 30-50 EUR/Host für APM, Custom Metrics nach Volumen. Open Source (Grafana Stack): Hosting-Kosten für die Backends, aber keine Lizenzkosten. Faustregel: 3-8 Prozent der Cloud-Kosten für Observability einplanen.
Datadog vs. Grafana — was ist besser?
Datadog: Beste UX, umfassendstes Feature-Set, höchster Preis, stärkster Vendor Lock-in. Grafana (OSS/Cloud): Flexibler, günstiger, OpenTelemetry-nativ, erfordert mehr Setup. Für Enterprise mit Budget: Datadog. Für kosten- und vendor-bewusste Teams: Grafana.
Was ist Observability-as-Code?
Dashboards, Alerts, SLOs und Instrumentierung als Code im Git-Repo verwaltet — nicht manuell in der UI konfiguriert. Tools: Terraform Provider für Datadog/Grafana, Grafana-as-Code, Prometheus Alerting Rules als YAML. Vorteile: Review-Prozess, Versionierung, Reproduzierbarkeit.
Wie starte ich mit Observability?
Drei Schritte: 1) OpenTelemetry SDK in die wichtigsten Services integrieren (Auto-Instrumentierung für Java, Python, Node.js). 2) Backend einrichten (Grafana Cloud Free Tier oder Datadog Trial). 3) Erstes Dashboard mit den vier Golden Signals (Latency, Traffic, Errors, Saturation) bauen. Ab dort iterativ erweitern.
Quelle des Titelbildes: Pexels / cottonbro studio
