Observability

KAPITEL 10 · ENTERPRISE IT

Observability

Mehr als nur Monitoring – verstehen Sie den internen Zustand Ihrer Systeme durch Logs, Metrics und Traces. Die Grundlage für zuverlässige, moderne IT-Infrastrukturen und Microservices-Architekturen.

Logs Metrics Traces OpenTelemetry

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite lernen Sie alles über Observability im Enterprise-Umfeld:

  • Definition: Was ist Observability und warum ist es wichtig?
  • Die drei Säulen: Logs, Metrics und Traces im Detail
  • Monitoring vs. Observability: Der entscheidende Unterschied
  • OpenTelemetry: Der offene Standard für Telemetriedaten
  • Tools & Plattformen: Prometheus, Grafana, ELK, Jaeger, Datadog
  • Best Practices: Naming, Cardinality, SLOs, Alerting
  • FAQ: Häufige Fragen und Antworten

1. Was ist Observability?

Definition

Observability (Beobachtbarkeit) ist die Fähigkeit, den internen Zustand eines Systems anhand seiner externen Ausgaben zu verstehen. Im Gegensatz zum klassischen Monitoring, das nur bekannte Probleme überwacht, ermöglicht Observability das aktive Erkunden und Debuggen von unbekannten Problemen in komplexen, verteilten Systemen.

In modernen Microservices-Architekturen und Cloud-nativen Anwendungen ist Observability unverzichtbar: Hunderte von Services kommunizieren miteinander, Fehler können an jeder Stelle auftreten und sind ohne umfassende Beobachtbarkeit kaum nachvollziehbar.

Der Kernunterschied: Monitoring sagt Ihnen, dass etwas nicht funktioniert. Observability sagt Ihnen, warum es nicht funktioniert – auch bei Problemen, die Sie noch nie gesehen haben.

Warum ist Observability heute so wichtig?

  • Komplexität: Microservices, Container und Serverless machen Systeme undurchschaubar
  • Dynamik: Auto-Scaling und Orchestrierung ändern die Topologie ständig
  • Geschwindigkeit: CI/CD-Pipelines deployen mehrmals täglich – Fehler müssen sofort erkannt werden
  • Abhängigkeiten: Ein Fehler in einem Service kann Kaskadeneffekte auslösen
  • Kundenerfahrung: Performance-Probleme direkt messen und beheben

2. Die drei Säulen der Observability

Observability basiert auf drei fundamentalen Datenarten, die zusammen ein vollständiges Bild des Systemzustands ergeben.

Logs

Diskrete Ereignisse & Nachrichten
„Was ist passiert?"

Zeitgestempelte Textnachrichten, die Ereignisse im System dokumentieren. Strukturierte Logs (JSON) sind maschinenlesbar und durchsuchbar.

  • Detaillierte Fehlermeldungen
  • Audit-Trails & Compliance
  • Debugging-Informationen
  • Kontext für Metriken & Traces
Typische Tools: Elasticsearch, Fluentd, Loki, Splunk

Metrics

Numerische Zeitreihen
„Wie verhält sich das System?"

Numerische Werte über Zeit: CPU-Auslastung, Request-Rate, Latenz, Fehlerrate. Ideal für Dashboards, Alerting und Trendanalyse.

  • Geringer Speicherbedarf
  • Schnelle Abfragen & Aggregation
  • Perfekt für Alerting & SLOs
  • Historische Trendanalyse
Typische Tools: Prometheus, Graphite, InfluxDB, Datadog

Traces

Verteilte Transaktionspfade
„Wo genau liegt das Problem?"

Verfolgen einer Anfrage über alle Services hinweg. Zeigt Latenzen, Abhängigkeiten und Bottlenecks in verteilten Systemen.

  • End-to-End-Sichtbarkeit
  • Service-Abhängigkeitskarten
  • Bottleneck-Identifikation
  • Korrelation mit Logs & Metrics
Typische Tools: Jaeger, Zipkin, Tempo, AWS X-Ray

Die Macht der Korrelation

Die wahre Stärke der Observability liegt in der Korrelation der drei Säulen: Eine Metrik zeigt einen Latenz-Anstieg → Ein Trace identifiziert den langsamen Service → Ein Log-Eintrag erklärt den Grund (z.B. Datenbank-Timeout). Ohne Korrelation bleiben die Daten isoliert und weniger aussagekräftig.

3. Monitoring vs. Observability

Monitoring und Observability werden oft synonym verwendet, beschreiben aber unterschiedliche Konzepte.

Monitoring

  • Überwacht bekannte Zustände
  • Beantwortet: „Ist das System gesund?"
  • Vordefinierte Dashboards & Alerts
  • Reaktiv: Warnt bei Schwellenwerten
  • Geeignet für monolithische Systeme
  • Fokus auf Infrastruktur-Metriken
VS

Observability

  • Ermöglicht Erkundung unbekannter Zustände
  • Beantwortet: „Warum verhält sich das System so?"
  • Ad-hoc-Abfragen & Exploration
  • Proaktiv: Verstehen vor dem Alert
  • Notwendig für verteilte Systeme
  • Fokus auf Anwendungs- & Business-Metriken

Fazit

Monitoring ist eine Teilmenge von Observability. Sie brauchen Monitoring für Alarme und Dashboards, aber Observability für tiefgreifendes Verständnis und Debugging. In modernen Architekturen ist Observability kein Luxus, sondern eine Notwendigkeit.

4. OpenTelemetry – Der offene Standard

Was ist OpenTelemetry?

OpenTelemetry (OTel) ist ein Open-Source-Framework der CNCF (Cloud Native Computing Foundation) für die Erfassung, Verarbeitung und Weiterleitung von Telemetriedaten (Logs, Metrics, Traces). Es entstand aus der Fusion von OpenTracing und OpenCensus und ist heute der De-facto-Standard für Observability-Instrumentierung.

Mit OpenTelemetry instrumentieren Sie Ihre Anwendung einmal und können die Daten an beliebige Backends senden – ohne Vendor-Lock-in.

Kein Vendor-Lock-in

Daten an jedes Backend sendbar: Prometheus, Jaeger, Datadog, etc.

Einheitliche API

SDKs für 10+ Sprachen: Java, Go, Python, Node.js, .NET, Rust, etc.

Auto-Instrumentation

Automatische Erfassung für Frameworks, Datenbanken, HTTP-Clients.

CNCF-Projekt

Graduiertes CNCF-Projekt mit breiter Industrieunterstützung.

5. Tools & Plattformen

Die wichtigsten Observability-Tools im Überblick – von Open Source bis kommerziell.

Prometheus

Metrics

Der Standard für Metrics-Erfassung und -Speicherung in Cloud-nativen Umgebungen. Pull-basiert mit PromQL.

  • Multi-dimensionales Datenmodell
  • Mächtige PromQL-Abfragesprache
  • Service Discovery
  • Alertmanager-Integration
Open Source CNCF Graduated

Grafana

Visualisierung

Die führende Plattform für Dashboards und Visualisierung. Unterstützt 50+ Datenquellen.

  • Rich Dashboards & Panels
  • Alerting & Notification
  • Loki (Logs) & Tempo (Traces)
  • Plugin-Ökosystem
AGPLv3 Grafana Labs

ELK Stack

Logs & Search

Elasticsearch + Logstash + Kibana. Der Klassiker für Log-Aggregation und Volltextsuche.

  • Volltextsuche & Aggregation
  • Kibana-Dashboards
  • Beats für Datenerfassung
  • Machine Learning Features
Elastic License Elastic

Jaeger

Distributed Tracing

Open-Source-Tracing-Plattform für Microservices. CNCF-graduiertes Projekt.

  • Distributed Context Propagation
  • Service Dependency Analysis
  • Performance & Latency Optimization
  • OpenTelemetry-kompatibel
Apache 2.0 CNCF Graduated

Datadog

Full-Stack Platform

All-in-One Observability-Plattform: Metrics, Logs, Traces, APM, Security, CI Visibility.

  • Unified Observability
  • 600+ Integrationen
  • AI-powered Anomaly Detection
  • Infrastructure Monitoring
Kommerziell SaaS

OpenTelemetry

Instrumentation Framework

Vendor-neutrales Framework für Erfassung und Export von Telemetriedaten. Der Industry-Standard.

  • Logs, Metrics, Traces
  • SDKs für 10+ Sprachen
  • Collector für Datenpipeline
  • Auto-Instrumentation
Apache 2.0 CNCF Incubating

6. Best Practices

Konsistentes Naming

  • Einheitliche Namenskonventionen für Metrics, Labels und Log-Felder
  • Präfixe für Namespaces: app_, infra_, business_
  • Snake_case für Metric-Namen, kebab-case für Label-Werte
  • Dokumentierte Naming-Guidelines im Team

Cardinality kontrollieren

  • Hohe Kardinalität (z.B. User-ID als Label) explodiert Speicher
  • Labels nur für Gruppierung, nicht für eindeutige IDs
  • Regelmäßige Cardinality-Audits durchführen
  • Recording Rules für häufige Aggregationen nutzen

SLOs definieren

  • Service Level Objectives als Messlatte für Zuverlässigkeit
  • Error Budgets für Balance zwischen Innovation & Stabilität
  • SLIs (Indikatoren) klar und messbar definieren
  • SLOs regelmäßig reviewen und anpassen

Intelligentes Alerting

  • Nur auf Symptome alerten, nicht auf Ursachen
  • Alert Fatigue vermeiden: Weniger, aber meaningful Alerts
  • Runbooks für jeden Alert erstellen
  • Alert-Routing nach Severity und Team

Die vier goldenen Signale

Laut Google SRE Book sind dies die vier wichtigsten Metriken für jeden Service:

  • Latency: Antwortzeit (unterscheiden nach Erfolg/Fehler)
  • Traffic: Request-Rate (Requests pro Sekunde)
  • Errors: Fehlerrate (als Anteil am Traffic)
  • Saturation: Auslastung (CPU, Memory, Disk, Connections)

7. FAQ – Häufige Fragen & Antworten

Häufige Fragen zu Observability

Brauche ich wirklich alle drei Säulen (Logs, Metrics, Traces)?

Idealerweise ja. Jede Säule hat ihre Stärken:

  • Metrics für Alerting und Dashboards (geringer Overhead)
  • Logs für detailliertes Debugging und Compliance
  • Traces für Performance-Analyse in verteilten Systemen

Für kleine Monolithen reichen oft Metrics + Logs. Für Microservices sind Traces unverzichtbar. Beginnen Sie mit Metrics und bauen Sie schrittweise aus.

Was ist der Unterschied zwischen APM und Observability?

APM (Application Performance Monitoring) ist ein Teilbereich der Observability, fokussiert auf Anwendungsperformance: Response Times, Error Rates, Transaction Tracing.

Observability ist breiter: Es umfasst APM, Infrastructure Monitoring, Log Management, Synthetic Monitoring, Business Metrics und mehr. APM ist ein Werkzeug innerhalb der Observability-Strategie.

Wie verhindere ich hohe Kosten bei Observability?
  • Sampling: Nicht jeden Trace speichern (z.B. 10% Sampling + alle Errors)
  • Retention Policies: Logs nach 30 Tagen löschen, Metrics aggregieren
  • Cardinality-Kontrolle: Hohe Kardinalität vermeiden (siehe Best Practices)
  • Log-Level: In Produktion nur WARN/ERROR, DEBUG nur bei Bedarf
  • Drop Rules: Unnötige Metrics/Logs bereits beim Erfassen filtern
  • Tiered Storage: Heiße Daten auf SSD, kalte auf Object Storage
Soll ich OpenTelemetry oder proprietäre Agenten verwenden?

Empfehlung: OpenTelemetry als Standard.

  • Vorteile OTel: Kein Vendor-Lock-in, einheitliche API, Community-Standard
  • Vorteile proprietär: Oft tiefer integrierte Features, einfacheres Setup

Viele kommerzielle Anbieter (Datadog, Dynatrace, New Relic) unterstützen mittlerweile OpenTelemetry nativ. Starten Sie mit OTel – Sie können später jederzeit wechseln oder ergänzen.

Wie starte ich mit Observability in einem bestehenden System?

Schritt-für-Schritt-Ansatz:

  1. Metrics first: Basis-Metriken (CPU, Memory, Request Rate, Error Rate) erfassen
  2. Strukturierte Logs: JSON-Logging einführen, Log-Aggregation aufsetzen
  3. SLOs definieren: Wichtigste Services identifizieren, Ziele festlegen
  4. Tracing hinzufügen: Kritische Pfade instrumentieren
  5. Dashboards bauen: Golden Signals für Top-Services
  6. Alerting konfigurieren: Symptom-basierte Alerts mit Runbooks

Beginnen Sie klein, messen Sie den Wert und erweitern Sie iterativ.

Was sind die häufigsten Fehler bei Observability?
  • Zu viele Metrics: Alles messen, nichts verstehen → Fokussieren auf Golden Signals
  • Alert Fatigue: Zu viele Alerts → Nur auf Symptome alerten
  • Fehlende Korrelation: Silos zwischen Logs/Metrics/Traces → Trace-ID überall propagieren
  • Keine SLOs: Keine Definition von „gut genug" → Error Budgets einführen
  • Hohe Kardinalität: User-ID als Label → Speicher explodiert
  • Keine Dokumentation: Niemand weiß, was ein Metric bedeutet → Metric Registry pflegen

Zusammenfassung

Die wichtigsten Punkte

  • Observability ≠ Monitoring: Monitoring warnt bei bekannten Problemen, Observability ermöglicht das Verstehen unbekannter Probleme
  • Drei Säulen: Logs (Was?), Metrics (Wie?), Traces (Wo?) – zusammen korrelieren
  • OpenTelemetry: Der offene Standard für Instrumentierung – kein Vendor-Lock-in
  • Golden Signals: Latency, Traffic, Errors, Saturation als Basis-Metriken
  • SLOs: Service Level Objectives definieren, was „zuverlässig genug" bedeutet
  • Cardinality: Hohe Kardinalität ist der häufigste Kostentreiber – kontrollieren!
  • Alerting: Auf Symptome alerten, nicht auf Ursachen – Runbooks erstellen
  • Tools: Prometheus + Grafana (Metrics), ELK/Loki (Logs), Jaeger/Tempo (Traces)

Nächste Schritte

Observability ist eine Reise, kein Ziel. Starten Sie mit den Grundlagen (Metrics + strukturierte Logs), definieren Sie SLOs für Ihre wichtigsten Services und bauen Sie schrittweise Tracing und erweiterte Analysen auf. Die Investition in Observability zahlt sich durch schnellere Incident Resolution, höhere Systemzuverlässigkeit und bessere Developer Experience vielfach aus.

Weiterführende Themen

Monitoring

Klassisches Monitoring, Nagios, Zabbix und Infrastructure Monitoring.

Zu Monitoring
Logging

Log-Management, ELK Stack, Fluentd und strukturierte Logs.

Zu Logging
SIEM

Security Information and Event Management für Sicherheitsanalysen.

Zu SIEM
Kubernetes Enterprise

Container-Orchestrierung und Cloud-native Observability in K8s.

Zu Kubernetes