Ist Observability die Zukunft des Monitorings?

Die alte Maxime „Man kann nicht verwalten, was man nicht messen kann” war für die Informationstechnologie noch nie so wahr wie heute. Mit der zunehmenden Einführung von Microservices, Containern und verteilten und serverlosen Modellen ist die Sichtbarkeit von Diensten und Infrastruktur für die Leistung der Systeme unerlässlich geworden. Als Reaktion auf dieses Szenario verlagert sich die Branche zunehmend von herkömmlichen Überwachungstools auf Beobachtungsfunktionen.

Observability bietet nicht nur High-Level-Überblicke über die Integrität von Systemen, sondern auch hochgranulare Einblicke in die von ihnen implizierten Fehlermodi. Wenn Sie eine komplett serverlose Anwendung in einer öffentlichen Cloud betreiben, ist Ihnen die dahinter liegende Infrastruktur nicht nur egal – Sie können sie auch nicht überwachen, selbst wenn Sie es wollten. Es gibt keine Möglichkeit, auf die Metriken des Netzwerks oder der Server oder Container zuzugreifen, auf denen Ihr Code ausgeführt wird. Was Sie in diesem Fall überwachen wollen, ist die Leistung Ihres eigenen Codes.

Die Überwachung wird im Voraus eingerichtet, was bedeutet, dass die Teams wissen müssen, was ihnen Sorgen bereiten könnte – und das, bevor ein Problem im System auftritt. Die Beobachtungsfunktion ermöglicht es Ihnen, herauszufinden, was wichtig ist. Das tun Sie, indem Sie beobachten, wie sich das System im Laufe der Zeit tatsächlich verhält, erklärt Ben Evans, JVM-Ingenieur und Architekt bei New Relic, in einem Artikel für InfoWorld.

Für viele wird Observability wie ein bequemes Rebranding von Anwendungsmonitoring klingen – und jede Skepsis gegenüber diesem Schlagwort ist berechtigt. Wie der InfoWorld-Kolumnist David Linthicum sagt, gibt es jedoch einen grundlegenden Unterschied: Monitoring „ist etwas, das man tut (ein Verb); Observability ist ein Attribut eines Systems (ein Substantiv)”.

Manche betrachten die Observability aber auch als eine Höchstmenge der Überwachung. Sie bietet nicht nur einen Überblick über die Systemintegrität auf hoher Ebene, sondern auch hochgranulare Einblicke in implizite Systemausfallmodi. Darüber hinaus bietet ein beobachtbares System reichlich Kontext über seine innere Funktionsweise. Das eröffnet die Möglichkeit, tiefer liegende systemische Probleme aufzudecken.

Neben dem, was wir unter traditioneller Überwachung verstehen, umfasst die Observability noch Metriken, Protokolle und Traces (die drei Säulen). Diese können jede beliebige Frage zu jedem beliebigen Zeitpunkt über die Vorgänge in einem komplexen Softwaresystem beantworten, indem man einfach den Betrieb des Systems beobachtet. Monitoring kann Ihnen sagen, ob Ihr System funktioniert, aber die Observability hilft Ihnen, tiefer zu ergründen, warum.

Ob Schlagwort oder nicht, Observability ist bereits ein grundlegender Aspekt der IT.

In vielerlei Hinsicht geht die Observability Hand in Hand mit APM. Denn ohne APM gibt es keine Observability. Ein System beobachtbar zu machen, setzt die Implementierung einer robusten Strategie zur Überwachung der Anwendungsleistung voraus. Und diese Strategie liefert einige der entscheidenden Mechanismen, mit denen sich der Zustand des Systems ableiten lässt.

Verbesserte Beobachtungsmöglichkeiten helfen DevOps-Teams bei der Bewältigung der Komplexität, die mit der zunehmenden Fragmentierung in verteilten Systemen einhergeht. Um dies zu erreichen, müssen Unternehmen verschiedene Prozesse implementieren. Diese sollten eine vollständige und effektive Überwachung der Anwendungsleistung, verteiltes Tracing und eine effektive Protokollverwaltung unterstützen. Dadurch wird sichergestellt, dass das Entwicklungs- und Betriebspersonal über alles verfügt, was es braucht, wenn die Systemstabilität aufgrund von Vorfällen in den Ressourcen einer Anwendung oder der unterstützenden Infrastruktur gefährdet ist.

APM wird fast immer mithilfe von Software wie Dynatrace, Paessler PRTG, SolarWinds Server & Application Monitor, Uptime und Broadcom DX Application Performance Management oder ähnlichem durchgeführt. Die Überwachung der Anwendungsleistung umfasst die Verfolgung von Systemmetriken und die Erstellung von Visualisierungen, die DevOps-Teams wichtige Daten zur Systemleistung liefern. Dies liefert einen wichtigen Kontext, um die Quelle von Anwendungsproblemen so schnell und effizient wie möglich zu identifizieren.

Die Observability hingegen ist eher ein Attribut als ein Prozess. Ein System gilt als beobachtbar, wenn sein Zustand ohne zusätzliche Implementierungen leicht ermittelt werden kann. In diesem Sinne stellt APM einen Teil der Werkzeuge und Prozesse dar, die erforderlich sind, um ein System beobachtbar zu machen. Obwohl die Konzepte per Definition unterschiedlich sind, wiederholen wir daher: Observability ohne APM ist nicht möglich.

Observability ergänzt also die Überwachung ­– ersetzt sie jedoch nicht. Zudem sollte sie nicht das Ziel an sich sein, sondern stattdessen als Mittel gesehen werden, um zuverlässigere Software für Kunden zu entwickeln und zu betreiben. „In der Lage zu sein, Produktionsprobleme schnell zu debuggen und zu diagnostizieren, trägt nicht nur zu einer optimalen Endbenutzererfahrung bei, sondern ebnet auch den Weg für eine humane und nachhaltige Betriebsfähigkeit eines Dienstes”, sagt Cindy Sridharan, Analystin bei QCom.

Der heilige Gral der Observability ist die Automatisierung eines Teils des Findungsprozesses – und zwar bis hin zu dem Punkt, an dem Probleme automatisch erkannt und behoben werden können, bevor sie sich auf die Nutzer auswirken. Noch besser ist es, wenn die Software selbst in der Lage ist, Fehler zu beheben, bevor die Entwickler in ihren Dashboards überhaupt auf das Problem aufmerksam werden.