Publiziert:

Observability

Ein System muss seinen inneren Zustand nach aussen zeigen

Observability (Beobachtbarkeit) ist die Fähigkeit, den inneren Zustand eines komplexen, verteilten Systems allein durch die Auswertung seiner externen Ausgaben (Telemetriedaten) zu verstehen. Sie geht über klassisches Monitoring hinaus: Nicht nur der Ausfall zählt, sondern die erklärbare Ursache.

In modernen Cloud-Architekturen ist Observability ein zentrales Mittel, Fehler zu verstehen, die über Systemgrenzen hinweg auftreten.

Anti-Patterns: Der Blindflug im Cluster

  • Silo-Monitoring: Jedes Team hat sein eigenes Dashboard, aber niemand sieht den kompletten Pfad einer Nutzeranfrage durch das System.
  • Log-Spam: Es werden Unmengen an Daten gesammelt, die aber im Fehlerfall nicht durchsuchbar sind oder keine relevanten Informationen enthalten.
  • Reactive Alerting: Alarme werden erst ausgelöst, wenn das System bereits steht, statt subtile Verschlechterungen (etwa steigende Latenz) frühzeitig zu erkennen.

Die drei Säulen der Observability

  1. Metrics: Quantitative Daten über die Zeit (CPU-Last, Request-Raten, Fehlerraten). Gut für Dashboards und Alarme.
  2. Logging: Detaillierte Text-Ereignisse. Unverzichtbar für die forensische Analyse einzelner Vorfälle.
  3. Distributed Tracing: Verfolgung einer einzelnen Nutzer-Anfrage über alle beteiligten Microservices hinweg. Zeigt genau, wo Zeit verloren geht oder ein Fehler entsteht.
  4. OpenTelemetry (OTel): Nutzung eines herstellerneutralen Standards zur Erfassung und Übertragung von Telemetriedaten, um Vendor Lock-in beim Monitoring zu vermeiden.
  5. Service Level Indicators und Objectives (SLI/SLO): Fokus auf die Metriken, die das Nutzererlebnis direkt widerspiegeln (etwa erfolgreiche Checkouts pro Minute). Ein SLO legt den Zielwert für eine solche Metrik fest, und das Alerting richtet sich danach aus, statt auf rohe Infrastruktur-Signale zu reagieren.

Der Fokus: Kürzere Fehlersuche

Die Zeit bis zur Fehlerbehebung (Mean Time To Recovery) sinkt massiv, da das System dem Ingenieur bereits die nötigen Fakten liefert, statt dass dieser mühsam auf Spurensuche gehen muss.

FAQ

Verursacht das Sammeln all dieser Daten nicht zu viel Zusatzlast?

Moderne Telemetrie-Frameworks wie OpenTelemetry sind auf niedrige Zusatzlast ausgelegt. Konkrete Kosten hängen von Sprache, Sampling-Rate und Kardinalität ab. Die Kosten eines ungelösten Systemausfalls überwiegen die Kosten für die Telemetrie in der Regel deutlich.

Müssen wir jetzt für jede Funktion Tracing-Code schreiben?

Nein. Moderne Frameworks bieten Auto-Instrumentation. Die Basis-Daten fliessen automatisch; manuelle Details sind nur dort nötig, wo sie für die fachliche Logik entscheidend sind.

Referenzen