Der Begriff Observability ist in aller Munde und oft wird der Begriff als moderne Lösung zu staubig altem, statischen Monitoring angepriesen. Alle Hersteller bieten es an, alle Benutzer brauchen es, am besten viel und jetzt sofort.
Liest man sich aber durch Produkt Beschreibungen und Blogartikel zu diesem Thema, fällt auf, das es keine wirklich einheitliche Definition des Begriffs gibt. Was meine ich damit? Je nach dem was man gerade liest, ist Observability manchmal „ein Ansatz zur besseren Beobachtbarkeit“ oder „ein Element moderner IT-Infrastrukturen“ oder „den Status eines Systems basierend auf seinem Output zu verstehen“ oder „ein Prozess für die Erkennung von Störungen“ oder eine „Eigenschaft eines Systems“. Natürlich ändern Begriffe gerne kontextbezogen ihre Bedeutung, aber mir scheint, dieser Begriff ist schon sehr überladen. Selbst Wikipedia wirft die Hände in die Luft und schreibt: „The definition of observability varies by vendor“.
Als ausgebildeter Linguist kann ich das nicht einfach ignorieren! Versuchen wir mal, die Begriffe Observability und Monitoring etwas zu genauer zu fassen. Zeit für etwas Etymologie!
Observability
Observability ist zunächst eine Wortzusammensetzung aus den Englischen Begriffen: „observe“ (engl. Verb to observe, beobachten) und „ability“ (engl. Substantiv, Fähigkeit). Das Ergebnis ist ein Substantiv, weil im Englischen die meisten Zusammensetzungen ihre Bedeutung vom Wort ganz rechts bekommen (rechtsköpfig, für die Linguisten in der Leserschaft). Wie im Deutschen übrigens, der Donaudampfschiffkapitän ist ja auch Kapitän und nicht Donau.
Observability beschreibt also die Fähigkeit etwas zu beobachten. Der Begriff ist übrigens nicht neu und wurde 1959 erstmals verwendet:
Observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs.
Kalman, Rudolf. „On the general theory of control systems.“ IRE Transactions on Automatic Control 4.3 (1959): 110-110.
Interessant hier, Kalman beschreibt Observability als „measure“ (engl. Substantiv, Maßeinheit), also eine Maßeinheit für wie gut man den Zustand eines Systems ableiten kann. Auch wenn der Kontext damals nicht die IT-Systeme im heutigen Sinne sind, findet man eine ähnliche Bedeutung in vielen aktuellen Texten.
Etwas komisch, der Begriff hat Fähigkeit (ability) im Wort, steht hier aber für eine Maßeinheit (measure), so ist das leider manchmal mit Sprache und „Obsermeasure“ rollt auch nicht so gut von der Zunge. Wie dem auch sei, diese Bedeutung ist zumindest greifbar und klar definiert. Wenn Observability also eine Fähigkeit und oder Maßeinheit ist, wer besitzt diese Fähigkeit oder das Maß? Drücken wir den „Grad an Observability“ unseres Systems aus, oder beschreiben wir unsere Fähigkeit als Operatoren das System zu beobachten?
Meine Theorie, es handelt sich dabei um beides. Lasst mich erklären: Unser System (IT-Infrastruktur oder Software) hat einen „Grad an Observability“, ist dieser „höher“ haben wir als Operatoren des Systems auch eine höhere Fähigkeit das System zu beobachten. Ein konkretes Beispiel:
Stellen wir uns vor wir haben eine Applikation, die aktuell keine Logs schreibt. Erweitern wir die Applikation mit einem Logging-Feature, ist ihr Grad an Observability und unsere Fähigkeit sie zu beobachten gestiegen. Oder kurz, die Applikation und wir haben mehr Observability. Fügen wir weitere Features hinzu, beispielsweise wenn unsere Applikation auch Performance Metriken liefert, ist die Observability wieder gestiegen.
OK, so weit so gut. Aber was machen wir jetzt mit dieser ganzen Observability, die unser System hat? Wir können beispielsweise die angefallenen Daten im Fehlerfall auswerten. Das kann reaktiv sein: Ich sehe also den Rauch, der aus dem Rechenzentrum kommt und suche die Ursache. Aber auch proaktiv: Ich schaue regelmäßig auf die Temperatur, bevor der Brand entsteht.
Hier kommt, meiner Meinung nach, der Begriff „Monitoring“ ins Spiel. Ziehen wir also nochmal unseren Linguistik-Laborkittel an.
Monitoring
Monitoring ist entweder das Substativ des Englischen Verbs „to monitor“ (überwachen) oder dessen erstes Partizip. In unserem Kontext (IT-Infrastruktur) taucht der Begriff, in der Regel, als „IT Monitoring“ auf. Wir können also davon ausgehen, das es sich um die Substativ Form handelt.
Es geht um die Überwachung von IT Systemen, oder den Prozess der Überwachung. Monitoring ist auch kein neuer Begriff. Eine kurze Recherche enthüllt dieses Zitat aus einen Mainframe Handbuch von 1963:
In addition […] there are large operational questions which will need to be determined in the areas of reliability, error detection, programming system and hardware maintenance under conditions of nearcontinuous operation, automatic traffic and performance monitoring, and automatic accounting.
The compatible time-sharing system: a programmer’s guide. MIT Press, 1963.
Monitoring meint zunächst alles was mit der Überwachung von IT Systemen. Dabei wird der Begriff oft zusätzlich qualifiziert, wie im Zitat oben „Performance Monitoring“, also die Überwachung der Leistung. Andere Beispiele sind „Status Monitoring“, „Service Level Monitoring“, oder „End to End Monitoring“.
Auffallend hier, dieses Monitoring wird immer von uns – den Operatoren – definiert. Was ist damit gemeint? Wir definieren welcher Status gut oder schlecht ist, wie das Service Level zu sein hat, oder was die beiden Enden im „End to End“ sind. Außerdem definieren wir, mit welchen Daten überwacht wird, welche Metriken beispielsweise relevant für das „Performance Monitoring“ sind.
Genau hier zeigt sich das Zusammenspiel zwischen den Begriffen Monitoring und Observability. Unser System braucht einen gewissen Grad an „Observability“ damit wir überhaupt erst „Monitoring“ machen können. Sobald wir Daten haben und basieren darauf Überwachung definieren, machen wir Monitoring.
Woher die Observability des Systems kommt, sollte dabei nicht strikt an bestimmten Daten ausgemacht werden. Oft liest man: „Metrics + Logs + Traces = Observability“, aber diese Aussage schränkt den Begriff aber viel zu sehr ein. Observability sollte jede Art von Daten beinhalten, die die Beobachtbarkeit eines Systems erhöhen.
Praxisbezug
OK, genug Theorie! Schauen wir uns mal an, ob meine Analyse in der Praxis tauglich ist. Die passenden Beispiele dafür suche natürlich ich selbst aus, so wie man das als ordentlicher Wissenschaftler macht.
Nehmen wir das OpenTelemetry Projekt und wenden die Begriffe an. OpenTelemetry ist unter anderem API Definitionen und SDKs für diverse Programmiersprachen, um Telemetrie Daten zu erzeugen. Beispielsweise Metriken, Logs und Traces. Das schicke daran, wir einigen uns alle auf einen Standard wie diese Daten abgebildet und übertragen werden.
Wir schnappen uns das passende SDK und bauen in unsere Applikation ein Feature ein, das Metriken uns Logs produziert. Diese kommuniziert die Applikation im OpenTelemetry Format mit dem OpenTelemetry Protokoll. Wir erhöhen also die Observability des Systems, weil wir jetzt mehr Daten haben, um den Zustand zu beobachten.
Daten alleine bringen uns aber nicht weiter. Installieren wir also beispielsweise den Grafana Stack, um die Daten zu speichern und auszuwerten. Wir melden uns in der Grafana Weboberfläche an und erstellen ein paar schicke Dashboards. Wir überwachen also den Zustand unserer Applikation über Daten, die wir als wichtig definieren. Wir machen Monitoring.
Das gleiche können wir auch auf Log Management Software wie beispielsweise Graylog anwenden (Fun Fact: Graylog unterstützt ab Version 6.2 auch OpenTelemetry). Stellen wir uns vor, wir haben noch keinen Einblick in unsere Server- und Netzwerkinfrastruktur Logs, unsere Observability ist also noch gering. Fangen wir nun an, die Daten zentral zu sammeln, erhöhen wir die Observability. In der Graylog Weboberfläche erstellen wir dann einige Benachrichtigungen für Alarme (zu viele fehlerhafte Anmeldeversuche beispielsweise). Wir definieren welche Daten relevant für die Überwachung sind, wir machen also Monitoring.
Funktioniert doch ganz gut oder? Klar, Bedeutung ist kontextbezogen, aber gleichzeitig sind unterschiedliche Definitionen für Begriffe in der IT Industrie nicht hilfreich. Wenn ich „Software“ sage, dann wissen wir doch auch alle was ich meine. Wir sollten ein gemeinsames Vokabular haben, damit wir das gleiche meinen wenn wir uns unterhalten. Sätze wie „the definition of <Begriff hier einfügen> varies by vendor“ dürfen nicht unser Goldstandard sein.
