Hochskalierbare IT-Konzepte sind auf dem Vormarsch, doch viele Admins überwachen ihre Systeme trotzdem so wie in der guten alten Zeit. Das ist oft lästig und im schlimmsten Fall gefährlich. Wie Sie als Administrator mit einem guten Monitoringkonzept für skalierbare Umgebungen auf Kurs bleiben, zeigt dieser Beitrag.
Kaum ein Trend hat die IT in den vergangenen Jahren so stark verändert wie der hin zu skalierbaren Umgebungen. AWS hat es mit der Amazon-Cloud vorgemacht, etliche andere Anbieter bemühen sich heute um ein Stück desselben Kuchens und einige Unternehmen bauen auf Basis von Produkten wie OpenStack gar ihre privaten Clouds. Das Ziel ist dabei immer dasselbe: Größtmögliche Flexibilität, hohe Automation und dadurch geringe Herstellkosten für gängige IT-Dienstleistungen.
Der Wettkampf der Plattformanbieter freut deren Kunden: Nie war es so leicht und mit einer so tiefen Einstiegshürde wie heute verbunden, IT-Workloads produktiv zu betreiben. Das wiederum wirkt sich auf die genutzten Programme aus: Wo vor etlichen Jahren noch große Monolithen das Bild der IT bestimmten, übernehmen heute immer häufiger moderne "Cloud Ready"-Anwendungen das Ruder. Die sind nicht nur implizit redundant, sondern dank der sie umgebenden Container auch sehr einfach zu betreiben. Container-Flottenverwalter wie Kubernetes tun ihr Übriges, um die IT der Gegenwart zu unterstützen.
Da reibt sich mancher Beobachter durchaus etwas verwundert die Augen, wenn er die Werkzeuge sieht, die viele Firmen noch immer nutzen, um moderne Workloads zu überwachen. Ganz gleich ob Plattformbetreiber oder Nutzer moderner Anwendungen: Viele Monitoringkonzepte der Gegenwart ließen sich problemlos auch im Jahre 2007 verorten oder haben gar ihre Ursprünge in diesem. Das ist schade, denn einerseits ist in skalierbaren Umgebungen viel mehr Monitoring nötig als das klassische Event-Monitoring der Vergangenheit.
Kaum ein Trend hat die IT in den vergangenen Jahren so stark verändert wie der hin zu skalierbaren Umgebungen. AWS hat es mit der Amazon-Cloud vorgemacht, etliche andere Anbieter bemühen sich heute um ein Stück desselben Kuchens und einige Unternehmen bauen auf Basis von Produkten wie OpenStack gar ihre privaten Clouds. Das Ziel ist dabei immer dasselbe: Größtmögliche Flexibilität, hohe Automation und dadurch geringe Herstellkosten für gängige IT-Dienstleistungen.
Der Wettkampf der Plattformanbieter freut deren Kunden: Nie war es so leicht und mit einer so tiefen Einstiegshürde wie heute verbunden, IT-Workloads produktiv zu betreiben. Das wiederum wirkt sich auf die genutzten Programme aus: Wo vor etlichen Jahren noch große Monolithen das Bild der IT bestimmten, übernehmen heute immer häufiger moderne "Cloud Ready"-Anwendungen das Ruder. Die sind nicht nur implizit redundant, sondern dank der sie umgebenden Container auch sehr einfach zu betreiben. Container-Flottenverwalter wie Kubernetes tun ihr Übriges, um die IT der Gegenwart zu unterstützen.
Da reibt sich mancher Beobachter durchaus etwas verwundert die Augen, wenn er die Werkzeuge sieht, die viele Firmen noch immer nutzen, um moderne Workloads zu überwachen. Ganz gleich ob Plattformbetreiber oder Nutzer moderner Anwendungen: Viele Monitoringkonzepte der Gegenwart ließen sich problemlos auch im Jahre 2007 verorten oder haben gar ihre Ursprünge in diesem. Das ist schade, denn einerseits ist in skalierbaren Umgebungen viel mehr Monitoring nötig als das klassische Event-Monitoring der Vergangenheit.
Andererseits sorgt klassisches Monitoring, das nicht an die Zeichen der Zeit angepasst ist, für unnötigen Mehraufwand. Viele Anwendungen kommen heute implizit redundant daher. Fällt von einer Applikation, die aus mindestens drei Instanzen besteht, eine aus, muss den Admin das aber gar nicht zwangsläufig kümmern. Genau dafür hat er ja Redundanz über mehrere Knoten. Ungeachtet dessen klingeln viele Firmen ihre Admins auch heute noch nächstens aus dem Bett, weil es irgendwo in der Umgebung ziept.
Dieser Artikel entwirft anhand mehrerer Faktoren ein Monitoringkonzept für die IT-Workloads der Gegenwart. Dabei geht es um die Infrastruktur ebenso wie um die tatsächlichen Workloads. Infrastruktur kann sich dabei durchaus auf verschiedene Elemente beziehen – wer als Unternehmen selbst eine Virtualisierungsplattform betreibt, ganz gleich ob mit OpenStack oder Kubernetes, trifft hier bereits auf spezifische Monitoringanforderungen. Wer seine Workloads lieber bei einem der Hyperscaler unterbringt, hat zwar diese Probleme nicht – dafür jedoch genügend andere. Wie kann modernes Monitoring in skalierbaren Umgebungen also aussehen?
Vom Monitoring, Alerting und Trending
Am Anfang aller Überlegungen steht wie so oft die Klärung einiger zentraler Begriffe. Wenn Administratoren von "Monitoring" sprechen, meinen sie damit meist das klassische Ereignismonitoring (Bild 1). Vordergründig geht es also um die Frage: Ist die zentrale Funktion eines Setups gegeben, funktionieren alle Dienste darin wie gewünscht und passieren gerade Dinge, die die Funktioinalität der Plattform in Gefahr bringen? Die allermeisten Administratoren dürften mit dieser Art des Monitorings auch schon in Kontakt gekommen sein. Ebenso kennen die meisten Admins der Thema Alerting – in klassischen Monitoring-Systemen ist es meist eine Einheit mit dem Monitoring. Erkennt das Ereignismonitoring ein Problem, gibt es über den definierten Kommunikationspfad automatisch eine Warnung aus.
Bild 1: Nagios und Co. funktionieren für Ereignismonitoring gut, nicht allerdings für das Sammeln von Metrikdaten. Das ist in skalierten Umgebungen aber kritisch.
Nicht ganz so stark im Fokus steht bei vielen Admins bis heute – sehr zu unrecht – das Thema Trending. Trending untersucht eine Plattform nicht darauf, ob sie gerade im Augenblick funktioniert, sondern trifft anhand verschiedener Parameter eine Prognose über die Verwendung von Ressourcen. Wer lediglich seine virtuellen Workloads zu verwalten hat, findet diese Information möglicherweise gar nicht so relevant – denn in der Cloud stehen virtuelle Ressourcen abgesehen von irgendwelchen Quotas beliebig zur Verfügung.
Wer aber eine eigene Plattform für Kubernetes oder OpenStack betreibt, will rechtzeitig wissen, wann dieser der Plattenplatz, der Speicher oder die verfügbare CPU-Leistung ausgeht (Bild 2). Denn jene Hardware, die das verhindern kann, kauft sich nicht von allein, schraubt sich nicht alleine ins Rack und installiert sich auch nicht selbst. Wer also Server betreibt, damit andere "serverless" sein können, braucht beim Skalieren in die Breite Vorlaufzeit. Und die lässt sich sinnvoll nur mit Trending erreichen. Daher gehen alle modernen IT-Konzepte davon aus, dass das Dreigespann Monitoring, Alerting und Trending (MAT) Dreh- und Angelpunkt moderner Überwachungssysteme sein muss. Da stellen sich die Fragen:
- Wie funktioniert das in der Praxis?
- Welche Tools stehen zur Verfügung?
- Was sind die typischen Best Practices?
- Worauf achtet der Administrator bei der Konfiguration?
Bild 2: Prometheus oder InfluxDB sind MAT-Werkzeuge, die das Monitoring über die Auswertung von Trending-Daten erledigen. Zeitreihendatenbanken ermöglichen das viel effizienter als üblich.
Trending als zentraler Aspekt
Gehen wir davon aus, dass Trending wie beschrieben eine schiere Notwendigkeit ist, hängen wir unser Monitoringkonzept idealerweise an diesem Aspekt auf. Auch moderne skalierbare Umgebungen brauchen Ereignismonitoring – die Sache ist allerdings: Klassische Werkzeuge für Ereignismonitoring sind üblicherweise schlecht darin, Trending-Daten zu sammeln und zu verwalten. Das gilt besonders für hochdynamische Umgebungen, die schnell wachsen oder schrumpfen und riesige Gesamtgrößen erreichen.
Jeder Admin, der mit PNP4Nagios in früheren Jahren zu tun hatte, kennt den Effekt: Je mehr Metrikdaten in der Datenbank lagern, desto träger wird die Abfrage. Obendrein ist für Trending in Werkzeugen wie Nagios, Icinga oder Zabbix kein allgemeiner Standard definiert. Es ist also schwierig, Trending-Daten aus diesen Werkzeugen heraus für andere Zwecke zu verwenden.
Trending-Werkzeuge setzen auf einen anderen Ansatz als Ereignismonitoring. Sie schreiben permanent beliebige Metrikdaten mit, machen diese aber mittels einer Zeitreihendatenbank verfügbar. Anders als bei PNP4Nagios und Co. werkelt hier also keine Datenbank mit Tabellen und Reihen. Stattdessen ist ein Zeitstrahl das Element, an dem die Daten in Trending-Systemen ausgerichtet sind. Monitoring ist dann als eine Art "Abfallprodukt" ebenfalls möglich: Der Zustand eines Dienstes X auf einem System ist ja auch nichts anderes als eine (sehr kurze) Zeitreihe. Fällt der Wert des freien Speicherplatzes im Root-Dateisystem unter fünf Prozent, lässt sich – das passende Werkzeug vorausgesetzt – ein Alarm auslösen. Wer deshalb auf moderne Trending-Systeme wie Prometheus oder InfluxDB setzt, benötigt in der Regel kein zusätzliches Ereignismonitoring mehr. Es wäre auch nicht sinnvoll, Infrastruktur für dieselbe Aufgabe doppelt zu betreiben.
Qual der Wahl
Die Diskussion hinsichtlich der Frage, welche Trending-Lösung der Administrator für seine Umgebung nutzen sollte, ist nicht sinnvoll zu führen. Prometheus und InfluxDB lassen sich mittlerweile – als zwei Beispiele von vielen – perfekt in Kubernetes, aber auch in Virtualisierungsumgebungen wie privaten Clouds einbinden. Auch der Funktionsumfang der gängigen Werkzeuge ähnelt sich stark. Prometheus hat in mancherlei Hinsicht die Nase leicht vorn, weil es von ihm keine kommerzielle Variante mit exklusiven Features gibt. Manche Features, die in InfluxDB der Bezahlversion vorenthalten sind, fehlen in Prometheus hingegen komplett.
Einen Cluster-Modus bietet das klassische Prometheus etwa gar nicht erst – hier muss der Administrator zu Thanos greifen, um Prometheus redundant zu gestalten. Falls mehrere voneinander unabhängige Prometheus-Instanzen keine Option sind – auch dieses Setup lässt sich nämlich hervorragend betreiben. Und die in Prometheus für Alarme zuständige Komponente "Alertmanager" beherrscht das Deduplizieren von Alarmen aus mehreren unabhängigen Prometheus-Instanzen perfekt. So oder so: Am Ende spielt die persönliche Präferenz des Admins sicher die größte Rolle bei der Entscheidung für oder gegen eine spezifische Lösung. Für das Beispiel geht der Artikel im weiteren Verlauf von Prometheus aus.
Ganz gleich ob Prometheus, InfluxDB oder eine andere Zeitreihendatenbank: Viel wichtiger ist die Frage, wie der Admin die Integration in seine Umgebung baut und wie er das jeweilige Werkzeug konfiguriert. Dabei spielen mehrere Faktoren eine Rolle: Wie erfährt das jeweilige System, welche Ziele zu überwachen sind, und welche Alarme ergeben in verteilten Umgebungen Sinn?
Physik überwachen
Gegeben sei also eine Umgebung etwa auf Basis von Open Nebula, die der Admin mit dem Werkzeug seiner Wahl überwachen möchte. Auch Virtualisierungsumgebungen können schnell und dynamisch wachsen, und Automation ist die Maxime der Stunde. Es ergibt deshalb Sinn, Prometheus die Konfiguration der zu überwachenden Hosts automatisch mit auf den Weg zu geben. Prometheus – wie InfluxDB auch – bietet hier mehrere Möglichkeiten an. Der Admin kann in seinem DNS-System die passenden SRV-Einträge hinterlegen, die Prometheus dann auswertet.
Wer ein DCIM-System wie Netbox nutzt, kann die Prometheus-Konfiguration aus diesem heraus auch automatisch durchführen lassen. Gerade Prometheus besticht zudem durch eine hohe Anzahl von Anbindungen an Virtualisierungssoftware, aus der heraus es die Hosts, die es überwachen soll, automatisch ausliest. Die Prometheus-Dokumentation hat die entsprechenden Details [1] (Bild 3). Ganz gleich, welches der verschiedenen Backends der Admin nutzen möchte: Die Erkennung von abzufragenden Diensten sollte stets automatisch geschehen. In einer Umgebung mit Hunderten oder Tausenden Systemen ist es schlicht nicht sinnvoll möglich, die Zielkonfiguration für MAT (Monitoring-und-Assesment-Tools) händisch zu pflegen.
Bild 3: Prometheus beherrscht das automatische Erkennen von Monitoringzielen, zum Beispiel über die Kubernetes-API.
Welche Daten Prometheus einsammeln soll, weiß dieses dadurch aber noch nicht. Alle Zeitreihendatenbanken unterstützen eine Vielzahl von Metriken. Sowohl in Prometheus als auch in InfluxDB (mit Telegraf) lesen dazu externe Dienste die Systeme aus und bieten die entsprechenden Daten zum Download an – oder senden sie an die jeweilige Zeitreihendatenbank. In Tools wie dem Alertmanager oder Grafana lassen sich aus diesen Daten dann Alarme generieren oder Graphen malen.
Grundsätzlich gilt: Prometheus wie Telegraf lesen von jedem konfigurierten Ziel stets alle dort verfügbaren Metrikdaten aus. Auf dieser Ebene unterscheidet der Admin also noch nicht – das passiert erst in den Tools, die die Metrikdaten aus der Zeitreihenbank tatsächlich auswerten. Die schlechte Nachricht ist: Welche Alarme ein Admin in Prometheus sehen möchte oder welche Zeitreihen in Grafana zu Panels werden, muss der Admin dann händisch konfigurieren – und zwar basiert auf den eigenen Bedürfnissen.
Welche Alarme sinnvoll sind
Mit eben dieser Festlegung tun sich viele Admins bis heute allerdings schwer – denn in massiv skalierten Umgebungen gelten andere Standards als in klassischen Setups. Wer etwa in seinem lokalen Setup Ceph nutzt und dieses mit einer MAT-Lösung überwachen möchte, wird naturgemäß die MON-Server von Ceph überwachen. Die erzwingen bei der Speicherlösung nämlich einerseits das Quorum und sind andererseits auch primärer Ansprechpartner für Clients, wenn diese sich über den Zustand des Clusters informieren wollen. Ein sinnvoll konstruierter Ceph-Cluster hat mindestens drei MON-Server.
Von diesen drei MON-Servern darf zu jedem Zeitpunkt ein MON-Server ausfallen, ohne dass der Cluster Probleme bekommt. Fällt ein MON-Server aus, springt der Zustand des Clusters zwar von "HEALTH_OK" auf "HEALTH_WARN" – er funktioniert aber weiterhin ohne Probleme. Noch offensichtlicher ist es, wenn der Admin anstatt drei MON-Servern fünf nutzt. Dann können sogar zwei MON-Server ausfallen, ohne dass der Cluster aufhört zu funktionieren. Entsprechend besteht in solch einer Situation auch keine Veranlassung, den Administrator mitten in der Nacht aus dem Bett zu klingeln. Wenn er sich nach dem Aufstehen am nächsten Morgen um das Problem kümmert, ist das früh genug.
In nicht wenigen Prometheus-Setups schlägt das Alarming los, sobald etwas im gesamten Setup nicht dem idealen Zustand entspricht. Ein Ceph-Cluster, der nicht im HEALTH_OK-Status ist, ist nicht ideal – aber wie beschrieben auch nicht unter allen Umständen ein Grund, nervös zu werden. Hier empfiehlt es sich aus Sicht des Administrators stattdessen, die vielen Möglichkeiten zu nutzen, welche moderne MAT-Systeme bieten. Und das wiederum geht auf verschiedenen Ebenen.
Bessere Alarme
Ein Grundsatz bei der Arbeit mit skalierbaren Systemen ist, möglichst viele Daten zu sammeln, aber möglichst fein einzustellen, unter welchen Bedingungen ein Alarm überhaupt generiert wird. Konfiguriert der Administrator im konkreten Beispiel einen Alarm, der lediglich den Status des HEALTH-Wertes von Ceph untersucht, wird er auch im beschriebenen Beispiel des Ausfalls eines MON-Servers einen Alarm generieren müssen – denn "HEALTH_WARN" kann auch ein Hinweis auf ein Problem sein, das der Admin sich sofort anschauen sollte, um größere Probleme zu verhindern.
Hängt der Admin seine Ceph-Alarmierung stattdessen an der Anzahl der aktiven MON-Server auf, sieht die Sache anders aus. Ceph exponiert ab Werk Metrikdaten über eine zu Prometheus und InfluxDB kompatible Schnittstelle, darunter auch eine Metrik, die die aktuell aktiven MON-Server wiedergibt. Fällt dieser Wert unter 2 (bei drei MON-Servern) oder unter 3 (bei fünf MON-Servern), ist Feuer am Dach. Andernfalls genügt es, das Problem später zu untersuchen.
Ganz ähnliche Regeln lassen sich für andere Komponenten skalierender Umgebungen ebenfalls definieren. Wer etwa OpenStack oder Kubernetes betreibt, muss nicht sofort Panik bekommen, wenn einer von drei Controller-Servern ausfällt. Denn genau deshalb sind diese ja redundant ausgelegt. Stürzt also ein Controller ab, reicht es, wenn der Admin sich am nächsten Tag darum kümmert.
Noch extremer wird die Situation, wenn die betriebene Plattform eine typische Public Cloud ist und ähnliche SLAs wie Amazon bietet. Das AWS-SLA besagt im Wesentlichen, dass die Plattform so lange als "up" gilt, wie ein Kunde seinen Workload automatisiert in irgendeiner AWS-Region starten kann. Die Aufgabe, den eigenen Workload redundant zu gestalten, tritt der Plattformanbieter also an den Kunden ab. Das ist für ihn bequem, denn das bedeutet freilich auch: Stürzt in der Nacht ein einzelner Compute-Knoten ab, muss der Admin das nicht zwangsläufig sofort geradebiegen. Und bis am nächsten Tag ein Reboot das System wieder zum Laufen bringt, haben die Kunden ihre Workloads ohnehin auf andere Server migriert oder per automatischer Skalierung das Problem anderweitig korrigiert.
Auch Alarmierung bietet Möglichkeiten
In skalierbaren Setups fährt der Admin also gut darin, zwischen kritischen und nicht-kritischen Problemen strenger als bisher zu unterscheiden und nur dann zu alarmieren, wenn die Plattform ein akutes Problem hat. Und zwar eines, das die Verfügbarkeit des Dienstes einschränkt (Loss of Functionality) oder die Nutzung der Cloud verunmöglicht (Loss of Control). Alle anderen Probleme können erfahrungsgemäß warten.
Im Netz findet sich insbesondere für Prometheus übrigens eine Liste fertiger Alarme für verschiedenste Dienste [2]. Prometheus selbst bietet wie InfluxDB den Parameter "severity" bei Alarmen, und die fertigen Alarme aus dem Web machen entsprechende Vorgaben. Die sind auf Wunsch veränderbar, stellen jedoch einen ganz guten Indikator für das dar, was die Entwickler der jeweiligen Tools für kritische Alarme halten. Durch den Severity-Wert bei Alarmen bietet sich für den Admin zudem eine weitere Stellschraube in Sachen Alarmierung. Denn nur, weil Prometheus einen Alarm generiert, muss nicht automatisch beim Admin das Handy klingeln.
Der Alertmanager von Prometheus etwa lässt sich mit verschiedenen Pagerdiensten wie PagerDuty oder OpsGenie koppeln (Bild 4). Die bieten wiederum eigene Möglichkeiten beim Finetuning der Alarmierung. Kritische Fehler und Warnungen ließen sich etwa getrennt voneinander in unterschiedliche Queues sortieren, die unterschiedliche Alarmierungszeiten haben und auch andere Personenkreise ansprechen.
Bild 4: Der Alertmanager von Prometheus kann Alarme deduplizieren und über eine große Zahl von Kanälen ausspielen. Das erhöht die Flexibilität des Admins.
Workloads effizient überwachen
Bis hierhin haben wir uns vorranggig mit dem Betrieb von Infrastruktur beschäftigt, etwa jenem von physischen Servern. Die gute Nachricht für die, die virtualisierte Workloads in der Cloud betreiben, ist diese: Die meisten Regeln, die für Blech gelten, sind auf virtelle Umgebungen anwendbar. Wer etwa Kubernetes für die Firma betreibt und dessen physische Knoten überwacht, kann Prometheus oder InfluxDB auch nutzen, um die Resourcen in Kubernetes zu prüfen.
Praktisch sind gängige MAT-Systeme und Kubernetes sogar darauf ausgelegt, ab Werk gut miteinander zu funktionieren. Service-Discovery kann Prometheus zum Beispiel auch betreiben, indem es sich unmittelbar mit der Kubernetes-API verbindet und sich dort eine Liste aller laufenden Pods abholt. Wer Workloads in Container verpackt, überwacht diese mit Kubernetes also automatisch mit, wenn das gewünscht ist.
Zusätzlich lässt sich Prometheus auch als eigener Pod in praktisch jeder beliebigen Container-Umgebung durch den Anwender selbst betreiben. Wer etwa seinen Workload auf AWS ausgelagert hat, wird in den meisten Fällen davon ausgehen, dass die grundlegende Infrastruktur funktioniert. Hier spielen andere Parameter eine Rolle:
- Laufen genug Instanzen der einzelnen Dienste meiner Mikroservices-Anwendung, um mit der anliegenden Last gut zurechtzukommen?
- Wie entwickelt sich der Traffic, was sind die Verbrauchswerte?
Gerade letztere Frage spielt auch finanziell eine Rolle. Beginnt eine Anwendung etwa aus dem Nichts das Tausendfache ihrer üblichen CPU-Last zu beanspruchen oder absurde Mengen an Traffic zu produzieren, kann das auf eine erhöhte Rückfrage zurückzuführen sein. Die weniger vorteilhafte, dafür aber viel wahrscheinlichere Variante ist, dass die App extern zweckentfremdet wird und jetzt Bitcoins mined, anstatt wie üblich Bücher zu verkaufen.
Weil Amazon nach Nutzung verrechnet, entstehen hier schnell hohe Rechnungen. Das gilt umso mehr, wenn automatische Skalierung aktiviert ist und in hoher zeitlicher Abfolge zusätzliche VMs hochfahren. In einer solchen Situation möchte der Admin nicht nur herausfinden, dass es ein Problem gibt, sondern über dieses schnell auch per Alarm informiert werden.
Fazit
Workloads in skalierbaren Umgebungen lassen sich effizient und sinnvoll überwachen, doch wird der Admin sich im Normalfall von konventionellen Tools wie Nagios und Co. verabschieden müssen. Stattdessen sind Trending-Werkzeuge nützlich, die das Ereignismonitoring nebenbei erledigen. Sie erst erlauben dem Admin, die Metrikdaten skalierbarer Umgebungen sinnvoll zu sammeln und zu interpretieren.
In Sachen Alerting steckt der Teufel dann im Detail. Wer seine Alarmierung so baut, wie er es schon immer getan hat, nutzt die Vorteile skalierbarer Setups kaum bis gar nicht sinnvoll aus. Stattdessen ist Flexibilität gefragt: Fällt von drei Nodes eines Clusters einer aus, muss der Admin nicht zwangsläufig aufstehen. Der Trend zu skalierbaren Umgebungen führt, richtig genutzt, also zu weniger Stress in der Bereitschaft.