Monitoring von Systemparametern wie CPU-Last, Speicherverbrauch et cetera – das entspricht den klassischen Metriken, die man schon seit Jahrzehnten mit Monitoring-Systemen abfragt. Warum sollte sich daran mit der Cloud etwas geändert haben?
Auch wenn die Definition der Cloud nicht für jeden gleich ist, sind sich die meisten doch einig, dass es auf jeden Fall auch darum geht, schnell (innerhalb von Minuten) Systeme erstellen und wieder löschen zu können. Das stellt neue Anforderungen an das Monitoring. Gehört es bei einem Hardwareserver teilweise noch dazu, dass man ihn nach Einbau manuell im Monitoring-System einträgt, kann es in der Cloud sein, dass der Server schon wieder gelöscht wurde, bevor man die Chance hatte, ihn im Monitoring einzutragen.
Mit der Cloud ist es auch möglich, mehrere hundert Server in kurzer Zeit zu erstellen. Möchte man sie alle manuell in einem Monitoring-System eintragen, wird man früher oder später kapitulieren müssen. Die Veränderung besteht also darin, größere Stückzahlen von Servern in kleineren Zeiteinheiten im Monitoring zu verwalten. Das ist nur mit Automatisierung zu lösen.
Welche Anforderungen muss ein Monitoring für die Cloud erfüllen?
Zuerst geht es darum, die unterschiedlichen Konzepte beim Monitoring genauer zu beleuchten:
- Push- versus Pull-Prinzip
- automatische versus manuelle Registrierung eines Servers
- mit oder ohne Agent
- Aufbewahrungsdauer der gespeicherten Daten
- Korrelation mit Ereignissen
Push- versus Pull-Prinzip
Bei zentralen Monitoring-Angeboten führt oftmals der Monitoring-Server Überprüfungen für jeden einzelnen Server aus und fragt die Ergebnisse ab (“pull”). Dem gegenüber steht das Prinzip, bei dem die Server ihre Überprüfungen selbst ausführen und die Ergebnisse an das Monitoring-System melden (“push”).
Solange die Anzahl der zu überwachenden Server gering ist, funktioniert das Pull-Prinzip. Sobald die Anzahl an Servern oder die Überprüfungen pro Server steigen, wird der Monitoring-Server zunehmend belastet – mit der Folge, dass er geeignet zu skalieren ist. Weiteren Aufwand bedeutet, dass man jeden Server, dessen Daten eingesammelt werden sollen, dem Monitoring-System bekannt geben muss.
Beim Push-Prinzip verlagert man einen Teil der Last auf die zu überwachenden Server. Je nach Monitoring-System erhalten die zu überwachenden Server auf unterschiedlichen Wegen ihre Überprüfungen. Diese führen sie dann lokal aus und senden die Ergebnisse an das Monitoring-System. Zusätzlich kann der zu überwachende Server beim Push-Prinzip die Daten zwischenspeichern, sodass sie sich optimiert über das Netzwerk verschicken lassen beziehungsweise sich ein Ausfall des Netzes oder des Monitoring-Servers überbrücken lässt.
Automatische versus manuelle Registrierung eines Servers
Bei einer kleinen Anzahl von Servern ist es durchaus noch gegeben, jeden neuen Server manuell im Monitoring-System einzutragen. Sobald neue Server aber in schneller Folge hinzugefügt werden, ist diese Aufgabe nicht mehr zu bewältigen. Das Monitoring-System sollte daher eine Möglichkeit bieten, über die sich Server selbst im System registrieren können. Dazu kann es durchaus sinnvoll sein, dass die Server neben ihrem Namen weitere Informationen übermitteln, damit ihnen die richtige Überwachung zugeordnet wird. So sind bei einem Datenbankserver andere Dinge zu überwachen als bei einem Webserver. Da diese Server in der Cloud automatisch aufgesetzt werden, kann die Automatisierungssoftware die zusätzlichen Informationen bereits mitliefern.
Beim Provisionieren eines Servers durch eine solche Automatisierungssoftware erhält man mit geringerem Aufwand direkt die Überwachung dazu. Voraussetzung ist allerdings das im vorherigen Abschnitt beschriebene Push-Prinzip. Lediglich der zu überwachende Server hat direkt nach der Installation alle Informationen, um das Monitoring einzurichten. Das Monitoring-System kennt den Server zu diesem Zeitpunkt noch nicht.
Mit oder ohne Agent?
Es gibt Monitoring-Systeme, die Server per Log-in abfragen, zum Beispiel bei Linux per ssh. Das System verbindet sich dabei mit dem Server, führt ein Kommando aus und verarbeitet das Ergebnis. Das ist eine spezielle Form des Pull-Prinzips. Es gelten daher die beschriebenen Beschränkungen.
Die Folge ist aber auch, dass ein Push-System inklusive automatischer Registrierung einen Agenten erfordert. Dieser ist Teil des eingesetzten Monitoring-Systems und lassen sich über die Automatisierungssoftware beim Provisionieren eines Servers direkt mit installieren.
Aufbewahrungsdauer der gespeicherten Daten
Eine Idee einer Cloud ist, dass es kurzlebige Systeme geben kann. Auch wenn sie nicht lange laufen, möchte man ihre Monitoring-Daten gegebenenfalls länger aufbewahren. Dazu muss das Monitoring-System in der Lage sein, die Daten eines Servers über den Zeitraum der tatsächlichen Überwachung hinweg vorzuhalten.
Das kann hilfreich sein, wenn man zum Beispiel unterschiedliche Softwarestände miteinander vergleichen oder Situationen in vergangenen Infrastrukturen analysieren möchte (z. B. bei Downscaling oder Blue/Green Deployments).
Korrelation mit Ereignissen
Ereignisse sind an dieser Stelle nicht gleichbedeutend mit Problemen, die in der Infrastruktur oder Anwendung geschehen, sondern gelegentlich oder regelmäßig auftretende Aktionen, zum Beispiel Deployments, Back-ups oder Updates. Sie können Auswirkungen auf die gemessenen Systemparameter haben. Es ist daher von Vorteil, wenn sie im Monitoring-System erscheinen – und nicht erst bei seinem Alarm in einer Excel-Tabelle, einem Wiki, Change-Management-Tool oder in einem sonstigen gesonderten Datenbestand nach einer Ursache zu suchen ist.
Die meisten Monitoring-Systeme sind darauf ausgelegt, kontinuierliche Werte als Zeitreihen aufzuzeichnen. Die beschriebenen Ereignisse gehören nicht in diese Kategorie. Es ist zu prüfen, ob das Monitoring-System gegebenenfalls andere Wege anbietet, solche Daten zu speichern, oder unterschiedliche Datenquellen in einer gemeinsamen Ansicht zusammenfassen kann.
Eventuell ist es an der Stelle sogar nötig, unterschiedliche Software einzusetzen, um die unterschiedlichen Daten zu speichern. Das ist aber nur sinnvoll, wenn es ein – gegebenenfalls wiederum separates – Dashboard gibt, das die Daten in einer Ansicht zusammenfassen kann. Getrennt betrachtet geben die Daten ansonsten nur bedingt Aufschluss über Zusammenhänge.
Monitoring und Docker
Docker ist als Container-Technik für Anwendungen gedacht. Aus Monitoring-Sicht kann man einen Container aber als eigenständigen Rechner verstehen – mit CPU, Arbeitsspeicher, Mount Points, mehreren Prozessen, Netzwerk et cetera.
Klassische Monitoring-Konzepte lassen sich aber nicht auf die Container anwenden. Ein Docker-Container hat keinen eigenen SSH-Server – es ist also ein Agent im Container zu installieren. Folglich würde dann in jedem Container ein eigener Agent laufen. Damit wird das Image größer, der Build komplizierter und die Portabilität schwieriger.
Docker hat zur Lösung des Problems die stats-API zur Verfügung gestellt. Damit ist es möglich, vom Docker Daemon Statistiken über alle Container eines Hosts aufzurufen. Das ermöglicht, einen einzigen Agenten auf dem Host zu installieren und alle Informationen über ihn abzufragen (s. Abb.). Die einzelnen Docker-Container bleiben somit unberührt vom Monitoring. Es lässt sich sogar der Monitoring-Agent in einem eigenen Container betreiben.
Monitoring-Agent in einem eigenen Docker-Container zur Überwachung aller anderen Container (Abb. 1).
Damit ist nur der erste Teil des Problems gelöst. Betrachtet man den Docker-Container nach wie vor für sich, werden die Statistikdaten nur mit der Docker-ID oder dem Namen des Containers an den Monitoring-Server gesendet. Hat man aber mehrere Server und auch die gleichen Images auf unterschiedlichen Servern, möchte man noch wissen, auf welchem der Container gerade läuft. Ansonsten sieht man im Monitoring gegebenenfalls ein Problem, kann aber nicht handeln, da nicht bekannt ist, auf welchem Host gerade einer von möglicherweise Hunderten gleichartiger Container Probleme hat.
Für dieses Problem ist es hilfreich, wenn das Monitoring-System gesendete Daten mit Metainformationen anreichern kann, darunter Host- und Docker-Image-Name. Dadurch erhalten die gesammelten Daten weiteren Kontext, der es ermöglicht, auf Ereignisse zu reagieren. Wie die zusätzlichen Daten den Messwerten zugeordnet werden, hängt stark vom eingesetzten Monitoring-System ab.
Fazit
Der Artikel hat einige grundlegende Kriterien für das Monitoring in der Cloud aufgezeigt. Sie sollen bei der Auswahl eines konkreten Produkts helfen, ohne dass hier im Artikel ein spezielles genannt worden wäre. Doch leider gibt es nicht die eine Lösung. Stattdessen ist für jede spezielle Cloud das jeweils geeignete Monitoring-Angebot zu finden. Hierbei kann es sein, dass die beste Lösung möglicherweise auch eine Kombination aus mehreren spezialisierten Systemen ist.
Quelle: http://www.heise.de/developer/artikel/Operations-heute-und-morgen-Teil-5-Monitoring-3118453.html