3 Min. Lesezeit
Das Wichtigste in Kürze
- Observability geht über Monitoring hinaus: Nicht nur bekannte Probleme erkennen, sondern unbekannte verstehen.
- Die drei Signaltypen Metrics, Logs und Traces bilden zusammen die Observability-Triade.
- OpenTelemetry ist der herstellerneutrale Standard für Telemetrie-Daten-Erfassung.
- Distributed Tracing visualisiert Request-Pfade über Microservices hinweg.
- Kosten für Observability-Plattformen können 5-15% der Cloud-Infrastrukturkosten erreichen.
Monitoring beantwortet die Frage: Funktioniert mein System? Observability beantwortet die Frage: Warum funktioniert es nicht? In verteilten Cloud-Systemen mit hunderten Microservices reicht klassisches Monitoring nicht mehr. Observability – die Kombination aus Metrics, Logs und Traces – macht komplexe Systeme debuggbar.
Von Monitoring zu Observability
Klassisches Monitoring prüft bekannte Zustände: CPU-Auslastung, Speicherverbrauch, HTTP-Statuscodes. Dashboards zeigen Rot oder Grün. Das funktioniert für monolithische Anwendungen mit vorhersagbaren Fehlermodi.
In Microservice-Architekturen versagt dieser Ansatz: Ein langsamer API-Call kann durch einen überlasteten Service drei Hops entfernt verursacht werden. CPU-Dashboards zeigen Grün auf allen Services – das Problem liegt in der Interaktion. Observability ermöglicht es, beliebige Fragen an das System zu stellen, ohne sie vorher definiert zu haben.
Die Observability-Triade: Metrics, Logs, Traces
Metrics sind numerische Zeitreihen: Request-Rate, Latenz (p50, p95, p99), Error-Rate, Queue-Depth. Prometheus hat sich als De-facto-Standard etabliert, ergänzt durch Grafana für Visualisierung. Metrics beantworten: Was passiert gerade?
Logs sind Texteinträge mit Kontext: Fehlermeldungen, Audit-Trails, Debug-Informationen. Structured Logging (JSON statt Freitext) macht Logs maschinell auswertbar. ELK Stack (Elasticsearch, Logstash, Kibana), Loki und Datadog Logs sind gängige Plattformen. Logs beantworten: Was ist passiert?
Traces verfolgen einen Request durch alle beteiligten Services. Jeder Hop wird als Span dokumentiert – mit Timing, Service-Name und Metadaten. Jaeger, Zipkin und Datadog APM visualisieren Trace-Waterfalls. Traces beantworten: Wo liegt das Problem?
OpenTelemetry: Der universelle Standard
Bevor OpenTelemetry existierte, war jedes Observability-Tool ein Vendor-Lock-in: Datadog-Agent, New Relic-Agent, Dynatrace-OneAgent – alle mit proprietärem Instrumentierung. Ein Wechsel erforderte Re-Instrumentierung des gesamten Codes.
OpenTelemetry (OTel) löst dieses Problem als herstellerneutraler Standard. Die Anwendung wird einmal mit OTel-SDKs instrumentiert und kann Telemetrie-Daten an jeden kompatiblen Backend senden – Grafana Cloud, Datadog, Honeycomb, Jaeger. Das OTel Collector empfängt, verarbeitet und exportiert Daten flexibel.
OTel ist ein CNCF-Projekt mit Unterstützung aller großen Observability-Vendor. Die Empfehlung ist klar: Neue Instrumentierung immer mit OpenTelemetry, nie mit proprietären Agents.
Kosten im Griff halten
Observability-Kosten können explodieren. Datadog-Rechnungen von 50.000+ Euro pro Monat sind bei mittelgroßen Unternehmen keine Seltenheit. Die Treiber: Jeder Log-Eintrag, jede Metrik und jeder Trace kostet Ingestion und Storage.
Strategien zur Kostenoptimierung: Sampling – nicht jeden Request tracen, sondern intelligent (Tail-Based Sampling tracet nur auffällige Requests). Log-Level-Management – Debug-Logs nur in Entwicklung, Info-Level in Produktion. Retention-Policies – Logs und Traces nach 30 Tagen in Cold Storage verschieben oder löschen.
Open-Source-Stacks (Prometheus + Grafana + Loki + Tempo) eliminieren Lizenzkosten, erfordern aber Betriebsaufwand. Der Trade-off: SaaS (teurer, weniger Aufwand) vs. Self-Hosted (günstiger, mehr Ops).
Alerting: Das Richtige zur richtigen Zeit
Zu viele Alerts sind schlimmer als keine Alerts – Alert Fatigue führt dazu, dass kritische Alerts übersehen werden. Best Practice: Alerts auf SLOs (Service Level Objectives) basieren, nicht auf einzelnen Metriken.
Statt „CPU > 80%“ zu alarmen (oft harmlos), definiert man: „99% der Requests sollen unter 200ms beantwortet werden.“ Wenn das Error Budget aufgebraucht ist, alerted das System – unabhängig davon, ob CPU, Memory oder ein externer Service die Ursache ist. Tools wie Sloth und Pyrra automatisieren SLO-basiertes Alerting auf Basis von Prometheus.
Häufige Fragen
Was kostet eine Observability-Plattform?
SaaS-Lösungen (Datadog, New Relic, Dynatrace) kosten typischerweise 5-15% der Cloud-Infrastrukturkosten. Bei einem Cloud-Spend von 100.000 €/Monat also 5.000-15.000 €/Monat. Open-Source-Stacks (Prometheus + Grafana + Loki) eliminieren Lizenzkosten, brauchen aber 0,5-1 FTE für Betrieb.
Ist OpenTelemetry produktionsreif?
Ja. Traces und Metrics sind seit 2023 stabil (GA). Logs haben 2024 GA erreicht. Alle großen Observability-Vendor unterstützen OTel. Die Empfehlung: Neue Projekte immer mit OTel starten. Migration bestehender Instrumentierung schrittweise.
Wie viel sollte man tracen?
Nicht alles. Tail-Based Sampling tracet nur Requests, die auffällig sind – hohe Latenz, Fehler, seltene Pfade. Das reduziert das Datenvolumen um 90-99% bei minimalem Informationsverlust. Head-Based Sampling (z.B. 10% aller Requests) ist einfacher, aber weniger intelligent.
Welche Observability-Plattform ist die beste?
Kommt auf den Kontext an. Datadog bietet die beste All-in-One-Experience, ist aber teuer. Grafana Cloud ist kostengünstiger und Open-Source-kompatibel. Honeycomb ist am besten für Query-basierte Exploration. Für kleine Teams: Grafana Cloud Free Tier oder selbst gehostetes Prometheus + Grafana.
Braucht man Observability für Monolithen?
Ja, aber weniger dringend als für Microservices. Metrics und Logs reichen für Monolithen oft aus. Traces werden relevant, sobald der Monolith externe Services aufruft (Datenbank, APIs, Message Queues). Der Einstieg über Prometheus + Grafana ist für jeden Tech-Stack sinnvoll.
Quelle des Titelbildes: Pexels / AS Photography
Lesetipps der Redaktion
- Lenovo ThinkCentre M75q Tiny Gen 5: Enterprise-Mini-PC mit AMD PRO und 5 Watt Idle für Edge und Kiosk
- Serverless KI ist überbewertet – hier ist was stattdessen zählt
- QNAP TS-464: 4-Bay-NAS mit Docker, HDMI und PCIe-Slot – was Synology in dieser Klasse nicht bietet
