Observability bezeichnet die Fähigkeit, aus dem, was ein System nach aussen abgibt, auf seinen inneren Zustand zu schliessen. Der Begriff grenzt sich von der klassischen Überwachung ab: Überwachung prüft vorher definierte Zustände, Observability erlaubt es, Fragen zu stellen, die man vorher nicht bedacht hat.
Warum die Unterscheidung zählt
Klassische Überwachung beantwortet bekannte Fragen: Läuft der Dienst, ist der Speicher voll, antwortet die Datenbank? Das genügt für bekannte Fehlerbilder. In verteilten Systemen sind die interessanten Störungen aber meist unbekannt: Eine bestimmte Anfrageart ist für eine bestimmte Kundengruppe langsam, aber nur zu bestimmten Zeiten. Diese Frage lässt sich nicht vorab als Prüfung anlegen — man muss sie im Nachhinein an die Daten stellen können.
Die drei Signalarten
Üblich ist die Unterscheidung in drei Arten. Logs sind Ereignisaufzeichnungen mit Detailtiefe; sie beantworten, was genau passiert ist. Metriken sind aggregierte Zahlenreihen über die Zeit; sie beantworten, wie viel und wie schnell. Traces verfolgen eine einzelne Anfrage über mehrere Dienste hinweg; sie beantworten, wo die Zeit geblieben ist. Jede Art allein hat blinde Flecken, und erst zusammen ergeben sie ein Bild.
Korrelation ist der eigentliche Wert
Der entscheidende Punkt ist nicht die Menge der gesammelten Daten, sondern die Fähigkeit, sie zusammenzuführen. Eine Metrik zeigt, dass Antwortzeiten gestiegen sind; ein Trace zeigt, welcher Schritt langsam ist; ein Log zeigt, warum. Ohne eine gemeinsame Kennung, die eine Anfrage über alle drei Ebenen hinweg identifizierbar macht, bleibt jede Ebene für sich und die Fehlersuche wird zum Raten.
Was alarmiert werden sollte
Die häufigste Fehlkonstruktion ist, auf technische Grössen zu alarmieren statt auf Auswirkungen. Eine hohe Prozessorlast ist kein Problem, solange die Nutzer nichts merken. Sinnvoll sind Alarme auf das, was Nutzer betrifft: Fehlerquote, Antwortzeit, Verfügbarkeit einer Kernfunktion. Alles andere gehört in ein Dashboard, das man bei Bedarf anschaut, nicht in eine Benachrichtigung, die jemanden weckt.
Alarmmüdigkeit
Zu viele Alarme sind schlimmer als zu wenige. Wer täglich Benachrichtigungen erhält, die keine Handlung erfordern, hört auf hinzusehen — und übersieht dann den einen, der zählt. Jeder Alarm sollte deshalb die Frage beantworten, was die geweckte Person konkret tun soll. Lässt sie sich nicht beantworten, ist es kein Alarm.
Praktische Konsequenz
Der pragmatische Einstieg besteht aus drei Schritten: eine durchgängige Anfragekennung über alle Dienste, strukturierte statt freitextlicher Logs, und eine kleine Zahl von Alarmen auf nutzerspürbare Wirkungen. Das ist deutlich weniger Aufwand als eine vollständige Observability-Landschaft und deckt den grössten Teil des Nutzens ab.