Observability

Was ist Observability?

Observability – auf Deutsch oft als Beobachtbarkeit übersetzt – ist die Fähigkeit, den internen Zustand eines IT-Systems anhand seiner externen Ausgaben (Logs, Metriken, Traces) zu verstehen und zu diagnostizieren. Während klassisches Monitoring dir sagt, DASS etwas nicht funktioniert, hilft Observability zu verstehen, WARUM es nicht funktioniert.

Für mittelständische Unternehmen, die zunehmend verteilte Systeme, Microservices und Cloud-Infrastruktur betreiben, ist Observability unverzichtbar. Ohne sie ist die Fehlersuche in komplexen Systemen wie die Suche nach der Nadel im Heuhaufen.

Die drei Säulen der Observability

Logs

Logs sind zeitgestempelte Aufzeichnungen diskreter Ereignisse. Sie erzählen die Geschichte, was in deinem System passiert ist: eine Fehlermeldung, ein erfolgreicher Login, ein fehlgeschlagener Datenbankzugriff. Strukturierte Logs (JSON-Format) sind deutlich besser durchsuchbar als unstrukturierte Textlogs.

Praxisbeispiel: Ein Logistik-Unternehmen erkennt anhand aggregierter Logs, dass die Auftragsverarbeitung jeden Montag um 9 Uhr für 15 Minuten langsamer wird – genau wenn der Wochenimport alter ERP-Daten läuft.

Metriken

Metriken sind numerische Werte, die den Zustand deines Systems zu einem bestimmten Zeitpunkt beschreiben: CPU-Auslastung, Antwortzeit, Fehlerrate, Anzahl aktiver Verbindungen. Im Gegensatz zu Logs sind Metriken aggregiert und benötigen wenig Speicherplatz, was sie ideal für langfristige Trendanalysen macht.

Wichtige Metriken für jede Anwendung: Anfragen pro Sekunde (Throughput), Antwortzeit (Latency), Fehlerrate (Error Rate) und Sättigung (Saturation). Diese vier Signale – bekannt als die „Four Golden Signals" von Google – decken die meisten Probleme auf.

Traces (Distributed Tracing)

Traces verfolgen eine einzelne Anfrage durch mehrere Services hindurch. In einem Microservices-System kann ein einzelner API-Aufruf zehn oder mehr interne Service-Aufrufe auslösen. Ein Trace zeigt, welcher Service wie lange gebraucht hat und wo Engpässe liegen.

Praxisbeispiel: Ein E-Commerce-Unternehmen stellt fest, dass die Produktseite 3 Sekunden zum Laden braucht. Der Trace zeigt, dass 2,5 Sekunden auf einen langsamen Empfehlungs-Service entfallen, der sequenziell statt parallel aufgerufen wird.

Observability vs. Monitoring

Monitoring und Observability werden oft verwechselt, ergänzen sich aber:

• Monitoring: Du definierst vorab, was du beobachten willst (z. B. CPU > 80 % → Alert). Monitoring beantwortet bekannte Fragen.
• Observability: Du kannst beliebige Fragen an dein System stellen, auch solche, die du beim Einrichten nicht vorhergesehen hast. Observability beantwortet unbekannte Fragen.

Monitoring ist ein Teilaspekt von Observability. Gutes Monitoring ist notwendig, aber nicht hinreichend für echte Observability.

Observability-Tools und Stacks

• Open-Source-Stack: Prometheus (Metriken) + Grafana (Dashboards) + Loki (Logs) + Tempo (Traces). Kostengünstig, aber mit Betriebsaufwand.
• ELK/EFK Stack: Elasticsearch + Logstash/Fluentd + Kibana. Stark für Log-Analyse, aber ressourcenintensiv.
• Cloud-native: AWS CloudWatch, Azure Monitor, Google Cloud Operations. Gut integriert, aber vendor-locked.
• SaaS-Lösungen: Datadog, New Relic, Dynatrace. Umfassend, aber teurer bei steigendem Datenvolumen.
• OpenTelemetry: Offener Standard für Telemetriedaten. Ermöglicht die instrumentierung einmalig zu implementieren und an verschiedene Backends zu senden.

Empfehlung für den Mittelstand

Für den Einstieg empfehlen wir den Prometheus + Grafana + Loki Stack. Er ist Open Source, gut dokumentiert und deckt Metriken, Logs und Dashboards ab. Für Distributed Tracing ergänze Tempo oder Jaeger. Wenn das Team klein ist und der Betriebsaufwand minimiert werden soll, kann eine SaaS-Lösung wie Datadog trotz höherer Kosten die bessere Wahl sein.