Die Zukunft des Monitorings bedeutet das Ende der IT-Infrastruktur

Nahezu täglich erscheinen Lösungen auf dem Markt, die die IT-Welt revolutionieren sollen. Doch setzen sich diese Lösungen nicht oft genug durch, um wirklich tiefgreifende Veränderungen zu initiieren.

Dies zeigt sich insbesondere auch beim IT-Monitoring, das schon längst nicht mehr nur auf die klassische Überwachung von IT-Systemen reduziert werden kann. Ganz im Gegenteil: Die Infrastruktur und die zugrunde liegende Hardware werden immer mehr zur Nebensache. Ein Kommentar von Greg Campion, Cloud-Entwickler der Paessler AG.

In den letzten Jahren gab es drei große Paradigmenwechsel in der operativen IT, die sich langfristig auch auf das Monitoring von IT-Systemen auswirken:

1. Die Virtualisierung und der damit einhergehende Übergang von einem Bare-Metal-Server mit einigen Anwendungen zu einem Server, auf dem mehrere virtualisierte „Server” betrieben werden. Diese Server wurden durch die Virtualisierung der zugrunde liegenden Hardware abstrahiert und erlauben es dem Administrator so, zahlreiche Server auf einem Bare-Metal-Server laufen zu lassen. Werden mehrere dieser Bare-Metal-Server miteinander verbunden, kann der Hypervisor (Virtualisierungssoftware) über den Cluster von Bare-Metal-Servern verwendet werden. Durch diese Verteilung wird eine gleichmäßige Arbeitsbelastung sichergestellt.
    
2. Die Einführung und der vermehrte Einsatz von Containern. Container teilen sich mit dem Konzept der Virtualisierung funktionale Eigenschaften, bringen aber die Abstraktion auf das nächste Level. Anstatt „nur“ die Hardware zu virtualisieren und auf jeder VM komplette Betriebssysteme auszuführen – was hinsichtlich Aktualisierung und Betrieb des Systems schon immer ein Problem war –, laufen Container auf dem Betriebssystem eines Hosts oder Netzknotens (Nodes). So lassen sich mehrere Workloads auf einem einzigen Betriebssystem ausführen.

   Diese Nodes können auf Bare-Metal-Basis oder als VMs existieren. Sie sollten lediglich über einen „Server“ verfügen, der mehrere Container ausführen kann. Die Möglichkeit, den Workload über diese Server zu verteilen, wird effizienter, da nicht mehr das komplette Betriebssystem und die gesamte Anwendung verschoben werden müssen. Stattdessen werden nur neue Instanzen der Anwendung verschoben oder erstellt, was weniger Platz beansprucht.
    

3. Auch Functions as a Service (FaaS) (oder Serverless Computing) ist auf Container zurückzuführen, da diese eine weitere Abstraktionsebene ermöglichen. Noch immer gibt es einen Server, der Funktionen ausführt; allerdings muss dieser nicht mehr im eigenen Unternehmen gewartet werden. Bei FaaS schreiben Softwareentwickler lediglich ihre Anwendungslogik und laden diese anschließend im FaaS-Dienst hoch – beispielsweise mit einem Public Cloud Provider wie AWS, Azure, Kubeless oder OpenFaaS. Daraufhin legen sie eine Art Trigger für die Anwendungslogik fest und können sich nun auf die Entwicklung ihrer Anwendung konzentrieren, anstatt sich um deren Ausführung kümmern zu müssen.

Infrastruktur und Hardware werden Massenware

Aufgrund dieser Abstraktion, die weg von Hardware führt, und der Flüchtigkeit moderner Anwendungen wird die IT-Infrastruktur als solche in den nächsten Jahren nur noch zur Nebensache. Denn wird eine serverlose 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 können auch die Container selbst nicht wirklich überwacht werden. Das einzige, das in diesem Fall überwacht werden 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 o. Ä. 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, wirklich von Bedeutung.

„Observability“ neuer Architekturen

Nun stellt sich natürlich die Frage: „Wie sollen wir dann monitoren?“ Dies ist nicht so leicht zu beantworten, denn es hängt ganz vom jeweiligen Business ab. Geht es aber um Anwendungen und Workloads, die auf einer modernen Infrastruktur ausgeführt werden, sollte man sich auf die Anwendung selbst konzentrieren.

In letzter Zeit tauchte zu dieser Thematik der Begriff „Observability“ (Beobachtbarkeit) auf. Der Gedanke dahinter ist, dass Observability neben dem, was aktuell noch als klassisches Monitoring betrachtet wird, auch Metriken, Protokolle und Traces (die drei Säulen der Beobachtbarkeit) umfasst. Diese werden direkt aus dem Workload oder der Anwendung gezogen oder auch verschoben, um sie besser sichtbar zu machen. Mit diesen Daten lässt sich der aktuelle Zustand eines Systems aus seinen externen Outputs ableiten.

Knotenpunkt Anwendungsmonitoring

Eine hohe Kardinalität in Überwachungsdaten haben Administratoren immer zu vermeiden gesucht. Aber um eine Anwendung „beobachtbar“ zu machen und zu gegebenem Zeitpunkt auf ein Problem eingehen zu können, scheint man um das Speichern wichtiger Daten nicht herumzukommen.
Ein Praxisbeispiel macht dies deutlich:

Der Systemadministrator erhält eine Warnmeldung, die ihm mitteilt, dass die Anwendung, die sein Kunde zum Bestellen von Widgets verwendet, eine Verzögerung aufweist. Außerdem verlässt eine größere Anzahl von Kunden die Seite, ohne den Bezahlvorgang abzuschließen. Um einen solchen Warnhinweis zu erhalten, muss der Weg jedes Kunden auf der Webseite durch dessen Standort protokolliert und überwacht werden. Nur durch das Speichern dieser Daten lässt sich demnach die Erfolgsrate bzw. der Check-out ermitteln. Um dem Problem auf den Grund zu gehen, wirft der Administrator also einen Blick auf die Ablaufverfolgung. Dort erkennt er, dass Timeouts auftreten, nachdem die Nutzer per Klick etwas in den Warenkorb gelegt haben. Durch integrierte Wiederholungsversuche wird das Element auch bei Zeitüberschreitungen noch hinzugefügt, allerdings ist die Nutzererfahrung in einem solchen Fall alles andere als optimal. Diese Tracing-Ebene bedeutet jedoch wiederum, dass für jede Ausführung der Anwendungslogik Daten gespeichert werden müssen, sodass diese Wiederholungsversuche sichtbar werden und sie mit den Anfragen der Kunden sowie mit den Kunden selbst verknüpft werden können.

Wurde ermittelt, welcher Teil der Anwendung Probleme verursacht, können die Protokolle für diese Logik überprüft werden. Um den Fehler zu finden, werden alle Protokolle dieses bestimmten Logikelements benötigt. Dabei lässt sich beispielsweise feststellen, dass die Schreibvorgänge beim Schreiben auf einen bestimmten Node des Datenbankclusters viel zu lange dauern und Timeouts verursachen.Schließlich kann sich der Administrator den Datenbankknoten ansehen und so feststellen, dass er mehr als die anderen Knoten beschrieben wird. Bei einem Blick in den Code der Anwendung zeigt sich nun, dass die Logik zum Schreiben auf die DB-Knoten fehlerhaft ist und dazu führt, dass die Daten ungleichmäßig geschrieben werden.

Beim Monitoring konzentrieren sich einige Administratoren noch immer auf bereits vorgekommene und somit erwartete Fehler, wodurch erhebliche Überwachungslücken entstehen. Um auch unbekannte Ereignisse sehen und darauf reagieren zu können, müssen Systeme besser beobachtbar gemacht werden. Für Viele ist Beobachtbarkeit nur ein Schlagwort für das, was jeder schon längst tun sollte. Allerdings bietet es auch eine neue Perspektive und damit eine Grundlage für ein neues Denken in Monitoring-Strategien, das moderne Systeme und die Einführung der Cloud unbedingt erfordern.

Greg Campion, Cloud-Entwickler der Paessler AG

www.paessler.de