Der Anfang der Observability
IT-Monitoring neu denken
Trends wie Virtualisierung, Container und Serverless Computing bringen klassische IT-Monitoring-Tools an ihre Grenzen. Nur mit einem neuen Ansatz lässt sich der Zustand hybrider Infrastrukturen und Applikationen überwachen.
In den letzten Jahren gab es drei große Paradigmenwechsel in der operativen IT: Virtualisierung, Container und Serverless Computing. Diese Technologien wirken sich jedoch nicht nur auf die IT an sich, sondern langfristig auch auf das Monitoring von IT-Systemen aus. Aus diesem Grund lässt sich IT-Monitoring schon längst nicht mehr nur auf die klassische Überwachung von IT-Systemen reduzieren. Systemadministratoren stehen vor der Herausforderung, komplexe und hybride Infrastrukturen sowie Applikationen zu überwachen. Dabei gewinnt die sogenannte "Observability" (Beobachtbarkeit) von Systemen und Applikationen an Bedeutung und soll das Monitoring zukünftig weiterentwickeln.
Klassische IT-Infrastrukturen und die zugrunde liegende Hardware werden immer mehr zur Nebensache. Um die verfügbaren Ressourcen in Unternehmen besser auszunutzen, entkoppelt man Speicher, Server oder Netzwerke zunehmend von der Hardware. Aufgrund dieser Abstraktion und der Flüchtigkeit moderner Anwendungen wird die IT-Infrastruktur als solche in den nächsten Jahren immer weiter zur Nebensache. Denn wird eine Server-lose Applikation vollständig in der Public Cloud ausgeführt, spielt die dahinterliegende Infrastruktur keine Rolle mehr. Hinzu kommt jedoch auch, dass sich eine solche Applikation nicht überwachen lässt. Es gibt keine Möglichkeit, über das Netzwerk oder die Server hinter den Containern, auf denen der Code ausgeführt wird, auf die Metriken zuzugreifen. Bis dahin lassen sich auch die Container selbst nicht wirklich überwachen. Das einzige, das der Administrator in diesem Fall überwachen kann, ist die Performance des Codes selbst.
Auch DevOps-Teams, die ihre Anwendungen in Containern auf einem gut aufgebauten Kubernetes-Cluster oder einem Managed-Cluster in der Cloud ausführen, sollten sich bei der Arbeit mit Containern keine Gedanken mehr über die Hardware machen. Die Verwaltung von K8-Clustern etc. wird immer mehr in die Cloud "ausgelagert", und weder die Hardware darunter noch die Cluster selbst sind für das Unternehmen, das die Anwendung ausführt, tatsächlich von Bedeutung.
Die Beobachtbarkeit neuer Architekturen
Auch wenn der Anwender bei der Nutzung von physischen oder virtuellen Services keinen Unterschied spürt, spielt diese Abstraktion bei der Arbeit von Systemadministratoren eine wichtige Rolle. Bereits mit relativ geringem Aufwand können sie virtuelle Umgebungen einrichten und verwalten. Weist ein virtuelles System einen Fehler auf, kann es zudem schnell wiederhergestellt werden, ohne dazu erst eine neue Hardware zu benötigen. Die Voraussetzung ist hier jedoch, dass bekannt ist, wo der Fehler liegt.
An diesen Punkten kommt nach wie vor das Monitoring ins Spiel. Mit einem geeigneten Tool lassen sich Systeme, Netzwerke und Applikationen bis ins kleinste Detail überwachen. Voraussetzung ist hier allerdings, dass sie über eine ausreichende Observability verfügen.
Bisher versuchten Administratoren, die Anzahl der gesammelten Überwachungsdaten möglichst gering zu halten. Um eine Anwendung "beobachtbar" zu machen und zu gegebenem Zeitpunkt auf ein Problem eingehen zu können, ist das Speichern wichtiger Daten jedoch erforderlich.
Denn Observability umfasst neben dem, was aktuell noch als klassisches Monitoring betrachtet wird, auch Metriken, Protokolle und Traces (die drei Säulen der Beobachtbarkeit). Diese zieht man direkt aus dem Workload oder der Anwendung, um sie besser sichtbar zu machen. Mit diesen Daten lässt sich der aktuelle Zustand eines Systems aus seinen externen Outputs ableiten.
Observability in der Praxis
Von seinem Monitoring-Tool erhält der Systemadministrator eine Warnmeldung über eine Verzögerung in einer Anwendung, die sein Kunde zum Bestellen von Widgets verwendet. Zudem verlässt eine größere Anzahl von Kunden die Seite, ohne den Bezahlvorgang abzuschließen. Um einen solchen Warnhinweis zu erhalten, muss IT-Verantwortliche den Weg jedes Anwenders auf der Webseite durch dessen Standort protokollieren und überwachen. Nur so lässt sich die Erfolgsrate beziehungsweise der Check-out ermitteln.
Um dem Problem auf den Grund zu gehen, dient dem Administrator die Ablaufverfolgung. Dort erkennt er, dass Timeouts auftreten, nachdem die Nutzer per Klick etwas in den Warenkorb gelegt haben. Diese Tracing-Ebene bedeutet, dass für jede Ausführung der Anwendungslogik das System Daten speichern muss, sodass diese Wiederholungsversuche sichtbar werden und sie sich mit den Anfragen der Kunden sowie mit den Kunden selbst verknüpfen lassen.
Hat der Administrator ermittelt, welcher Teil der Anwendung Probleme verursacht, kann er die Protokolle für diese Logik überprüfen. Um den Fehler zu finden, benötigt man alle Protokolle dieses bestimmten Logikelements. Dabei lässt sich beispielsweise feststellen, dass die Schreibvorgänge beim Schreiben auf einen bestimmten Node des Datenbank-Clusters viel zu lange dauern und Timeouts verursachen. Um solche Informationen zu erhalten, muss die Anwendung bei jeder Ausführung detaillierte Daten ausgeben.
Durch die Informationen über die Datenbankknoten kann der Administrator erkennen, dass ein Knoten mehr als die anderen Knoten beschrieben wird. Bei der Betrachtung des Codes der Anwendung zeigt sich nun, dass eine neue Code-Version zum Einsatz kommt. Für die Interaktion mit der Datenbank nutzt dieser neue Code eine andere Bibliothek, die deutlich langsamer ist als die vorherige, wodurch sich zwangsläufig auch die Schreibvorgänge verlangsamen. Mit diesen Informationen kann der Administrator diese Änderung zurücksetzen, den Code korrigieren und erneut ausrollen.
Eine solche Analyse ist nur dann möglich, wenn ein beobachtbares System ausgeführt wird. Werden stattdessen nur die Statistiken der DBs und der Hosts überwacht, auf denen die Anwendung ausgeführt wird, wäre ein solches Problem gar nicht erst aufgefallen. Häufig beachtet man solche Aspekte dann, wenn sie so oder so ähnlich schon einmal aufgetreten sind. Doch bei der Observability geht es gerade um das Monitoring dieser "unbekannten Unbekannten" in der eigenen Umgebung.
Die "unbekannten Unbekannten" überwachen
Beim Monitoring basieren Dashboards und Sensoren meist auf früheren Erfahrungen. Viele Administratoren konzentrieren sich noch immer auf bereits vorgekommene und somit auch zukünftig erwartete Fehler; dabei handelt es sich um die sogenannten unbekannten Bekannten.
Was ein Unternehmen letztlich sogar ruinieren kann, sind die "unbekannten Unbekannten". Das sind die Aspekte, die der Systemadministrator nicht wahrnimmt, nicht versteht und somit auch nicht überwacht. An diesem Punkt kommt schließlich die Observability ins Spiel. Um diese unbekannten Ereignisse - die eintreten können und werden - sehen und darauf reagieren zu können, müssen Systeme besser beobachtbar sein.
Fazit
Für viele Systemadministratoren ist Observability nur ein Schlagwort für das, was IT-Abteilungen schon längst tun sollten. IT-Abteilungen müssen immer komplexere und verteiltere Systeme managen. Um die Verfügbarkeit der Systeme und Applikationen und somit auch eine gute Nutzererfahrung sicherzustellen, ist es unerlässlich, diese Erfahrung zu simulieren und zu verfolgen. Dies sollte bei allen kritischen Systemen durchgeführt werden. Sobald jedoch ein Problem erkannt wird, muss der Verantwortliche in der Lage sein, die Daten aus den Systemen in der Blackbox zu analysieren. Auf diese Weise lassen sich neue Aspekte erkennen und in das Monitoring aufzunehmen. Die Beobachtbarkeit von Systemen kann man demnach weiterentwickeln und so Alarmierungen verbessern, Troubleshooting vereinfachen und Überwachungslücken schließen.
Solche Entwicklungen sind bei modernen Systemen und durch die Einführung der Cloud unbedingt erforderlich, um die komplexen Unternehmensinfrastrukturen bestmöglich unter Kontrolle zu haben und im Ernstfall schnell reagieren zu können.
Lesen Sie mehr zum Thema
