Der Unterschied zwischen Monitoring und Observability in verteilten Systemen

Klassisches Monitoring beruht auf vorab bekannten Fragen: Läuft der Server, liegt die CPU-Last über 80 Prozent, läuft die Festplatte voll, ist der nächtliche Job durchgelaufen? Ein Betreiber wählt ein Signal, setzt einen Schwellenwert und alarmiert bei dessen Überschreitung. Für eine kleine Zahl von Servern mit einem Monolithen funktioniert das gut, denn die Liste möglicher Fehler ist kurz, und die Bereitschaftsmitarbeiter kennen sie auswendig.

Die Grenze liegt darin, dass jede Prüfung eine Vorhersage abbildet. Tritt ein Fehler auf, den niemand vorhergesehen hat – etwa eine langsame nachgelagerte Abhängigkeit, ein Retry-Sturm oder ein Cache, der technisch läuft, aber veraltete Daten liefert –, bleiben die Dashboards grün, während sich Kunden beschweren. Monitoring bleibt notwendig, reicht aber nicht mehr aus, sobald das System größer ist als das mentale Modell eines einzelnen Menschen.

Verlagert man dieselbe Geschäftsfunktion in ein Dutzend Dienste mit einer Message Queue dazwischen, ändern sich drei Dinge. Erstens berührt eine einzelne Benutzeranfrage nun viele Prozesse auf vielen Hosts, sodass keine einzelne Logdatei das ganze Bild zeigt. Zweitens werden Ausfälle partiell: Eine Region, ein Mandant oder ein Codepfad ist langsam, während das Gesamtbild gesund aussieht. Drittens ändert sich das System mehrmals täglich, sodass die Baseline von gestern nicht mehr gilt.

Observability ist die Eigenschaft, den inneren Zustand eines Systems aus den Daten zu verstehen, die es aussendet – ohne neuen Code ausliefern zu müssen, um eine neue Frage zu stellen. In der Praxis bedeutet das, umfangreiche Telemetrie mit hoher Kardinalität zu erfassen (welcher Kunde, welcher Endpunkt, welche Version, welche Region) und sie bei Bedarf beliebig aufschlüsseln zu können. Die Frage verschiebt sich von „Läuft das System?“ zu „Welche Benutzer erleben Verzögerungen, seit wann, und was hat sich geändert?“

Ein Service Level Objective ist ein Zielwert für eine nutzerbezogene Kennzahl, zum Beispiel: 99,9 Prozent der Checkout-Anfragen werden innerhalb von 500 Millisekunden erfolgreich abgeschlossen, gemessen über 30 Tage. Prozentsatz und Zeitfenster legt die Organisation fest; entscheidend ist, dass das SLO beschreibt, was Benutzer erleben, und nicht, was ein Host meldet.

Ein SLO definiert ein Fehlerbudget – das Maß an Ausfällen, das im Zeitfenster verkraftbar ist – und damit ein anderes Alarmierungsmodell. Statt bei Überschreiten einer CPU-Grenze zu alarmieren, alarmiert das Team, wenn das Budget zu schnell verbraucht wird, um bis zum Ende des Zeitfensters zu reichen (Burn-Rate-Alarm). Langsamer Verbrauch wird zum Ticket für den nächsten Arbeitstag; schneller Verbrauch alarmiert den Bereitschaftstechniker. Allein diese Änderung beseitigt die meisten Alarme, auf die niemand reagieren muss.

SLOs geben Technik und Fachbereichen zudem eine gemeinsame Sprache. Ist das Budget gesund, kann das Team schneller ausliefern; wird es aufgebraucht, investiert das Team in Zuverlässigkeit. Ein CPU-Diagramm kann dieses Gespräch nicht tragen.

Der häufigste Fehler von Monitoring-Programmen ist ein Zuviel an Alarmen, nicht ein Zuwenig. Erhält ein Bereitschaftsdienst Dutzende Alarme pro Woche, von denen die meisten kein Handeln erfordern, hören die Mitarbeiter auf, sie zu lesen, und der eine wichtige Alarm geht im Rauschen unter. Jeder Alarm sollte einen einfachen Test bestehen: Eine Person muss sofort etwas dagegen tun können. Ist das nicht der Fall, gehört er auf ein Dashboard oder in einen Tagesbericht, nicht in eine Alarmierung.

Behandeln Sie die Alarmregeln wie Code, der einem Review unterliegt. Jeder Alarm hat einen Verantwortlichen, einen Runbook-Link und eine Daseinsberechtigung; Alarme, die einen Monat lang ohne Handlungsbedarf auslösen, werden gelöscht oder herabgestuft. Messen Sie den Bereitschaftsdienst selbst: Alarme pro Woche, Alarme außerhalb der Arbeitszeit, Zeit bis zur Bestätigung. Ein gesunder Bereitschaftsdienst ist ein Zeichen für ein gesundes System, ein ungesunder ein klarer Hinweis darauf, wo investiert werden sollte.

Verteilte Systeme stellen eine weitere Anforderung: Alarme sollten Kontext mitliefern. Ein Alarm mit dem Text „error rate high on payments-api“ ist eine Rechercheaufgabe; ein Alarm, der auf das betroffene SLO, das letzte Deployment und den am häufigsten fehlschlagenden Endpunkt verweist, ist eine Entscheidungsgrundlage.

Observability-Daten haben ihren Preis, und die Rechnung kommt meist erst, wenn sich die Gewohnheit bereits eingeschliffen hat. Die beiden Kostentreiber sind Volumen (Bytes an Logs und Spans pro Anfrage, multipliziert mit dem Datenverkehr) und Kardinalität (die Zahl unterschiedlicher Label-Kombinationen einer Metrik). Eine Metrik mit Benutzer-ID oder Anfrage-ID als Label erzeugt für jeden Wert eine neue Zeitreihe und überlastet jeden Metrikspeicher.

Sinnvolle Standardeinstellungen bewirken bereits viel. Halten Sie Identifikatoren mit hoher Kardinalität in Traces und strukturierten Logs statt in Metrik-Labels. Erfassen Sie Traces stichprobenartig: jeden Fehler und jede langsame Anfrage, von den normalen Anfragen nur einen Teil. Legen Sie die Aufbewahrung je Signal fest: Metriken ein Jahr lang in reduzierter Auflösung, Logs für Wochen, Traces für Tage, dazu eine Archivstufe für alles, was die Compliance verlangt. Prüfen Sie monatlich, welche Quellen das meiste Log-Volumen erzeugen; eine einzige ausführliche Debug-Ausgabe in einem häufig durchlaufenen Codepfad kann einen großen Teil der Rechnung ausmachen.

Ziel ist nicht, alles zu sammeln, sondern die nächste unbekannte Frage schnell beantworten zu können – zu Kosten, die das Unternehmen dauerhaft zu tragen bereit ist.