Monitoring für die Cloud

In diesem Artikel geht es um das Monitoring von Systemparametern wie CPU-Last, Speicherverbrauch etc. innerhalb einer Cloud. Das sind die klassischen Metriken, die man schon seit Jahrzehnten mit Monitoringsystemen abfragt. Warum sollte sich daran mit der Cloud etwas geändert haben?

Was hat sich geändert?

Auch wenn die Definition der Cloud nicht für jeden gleich ist, so sind sich die meisten doch einig, dass es darum geht, schnell (innerhalb von Minuten) Systeme erstellen und auch wieder löschen zu können. Dies stellt neue Anforderungen an das Monitoring. Gehört es bei einem Hardwareserver teilweise noch dazu, dass man ihn nach Einbau manuell im Monitoringsystem einträgt, so 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 diese Server alle manuell in einem Monitoringsystem 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. Dies ist nur mit Hilfe von Automatisierung zu lösen. Wie diese Automatisierung speziell beim Monitoring aussieht, werden wir in den nächsten Abschnitten betrachten.

Welche Anforderungen muss ein Monitoring für die Cloud erfüllen?

In diesem Teil möchte ich die unterschiedlichen Konzepte beim Monitoring genauer beleuchten:

• push vs. pull
• Automatische vs. manuelle Registrierung eines Servers
• Mit oder ohne Agent
• Aufbewahrungsdauer der gespeicherten Daten
• Korrelation mit Ereignissen

push vs. pull

Bei zentralen Monitoringlösungen führt oftmals der Monitoringserver Überprüfungen für jeden einzelnen Server aus und fragt die Ergebnisse ab (pull). Dem gegenüber steht das Prinzip, dass die Server ihre Überprüfungen selbst ausführen und die Ergebnisse an das Monitoringsystem melden (push).
Solange die Anzahl der zu überwachenden Server gering ist, funktioniert pull. Sobald die Anzahl an Servern oder Überprüfungen pro Server steigt, wird der Monitoringserver zunehmend belastet und muss geeignet skaliert werden. Weiterer Aufwand ist, dass man jeden Server, dessen Daten eingesammelt werden sollen, dem Monitoringsystem bekannt geben muss.
Bei push verlagert man einen Teil der Last auf die zu überwachenden Server. Je nach Monitoringsystem erhalten die zu überwachenden Server auf unterschiedlichen Wegen ihre Überprüfungen. Diese führen sie dann lokal aus und senden die Ergebnisse an das Monitoringsystem. Zusätzlich kann bei push der zu überwachende Server die Daten zwischenspeichern, so dass sie optimiert über das Netzwerk verschickt werden können bzw. einen Ausfall des Netzes oder des Monitoringservers überbrückt werden kann.

Automatische vs. manuelle Registrierung eines Servers

Wie oben schon geschrieben ist es bei einer kleinen Anzahl von Servern durchaus noch möglich jeden neuen Server manuell im Monitoringsystem einzutragen. Sobald neue Server aber in schneller Folge hinzugefügt werden, ist diese Aufgabe nicht mehr zu bewältigen. Das Monitoringsystem 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 Servernamen auch noch weitere Informationen übermitteln, damit den Servern die richtige Überwachung zugeordnet wird. So müssen bei einem Datenbankserver andere Dinge überwacht werden als bei einem Webserver. Da in der Cloud diese Server automatisch aufgesetzt werden, können die zusätzlichen Informationen bereits durch die Automatisierungssoftware mitgeliefert werden.
Beim Provisionieren eines Servers durch eine 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 nötigen Informationen um das Monitoring einzurichten. Das Monitoringsystem kennt den Server zu diesem Zeitpunkt noch nicht.

Mit oder ohne Agent?

Es gibt Monitoringsysteme, die Server per Login abfragen, z. B. bei Linux per ssh. Das Monitoringsystem verbindet sich dabei mit dem Server, führt ein Kommando aus und verarbeitet das Ergebnis. Dies ist eine spezielle Form des pull-Prinzips. Es gelten daher die bereits beschriebenen Beschränkungen. Die Folge ist aber auch, dass ein push-basiertes System inkl. automatischer Registrierung einen Agenten erfordert. Diese Agenten sind Teil des eingesetzten Monitoringsystems und lassen sich über die Automatisierungssoftware bei der Provisionierung eines Servers direkt mit installieren.
Aufbewahrungsdauer der gespeicherten Daten

Eine Idee einer Cloud ist, dass es kurzlebige Systeme geben kann. Auch wenn diese Systeme selbst nicht lange laufen, möchte man ihre Monitoringdaten ggf. länger aufbewahren. Dazu muss das Monitoringsystem in der Lage sein, die Daten eines Servers über den Zeitraum der tatsächlichen Überwachung hinweg vorzuhalten. Dies kann hilfreich sein, wenn man z. B. 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 auftreten, sondern gelegentlich oder regelmäßig auftretende Aktionen, z. B. Deployments, Backups oder Updates.
Diese Ereignisse können Auswirkungen auf die gemessenen Systemparameter haben. Es ist daher von Vorteil, wenn diese Ereignisse im Monitoringsystem erscheinen und nicht erst bei einem Alarm des Monitoringsystems in einer Excel Tabelle, einem Wiki, Change-Management-Tool oder sonstigem gesonderten Datenbestand nach einer möglichen Ursache gesucht werden muss.
Die meisten Monitoringsysteme sind darauf ausgelegt kontinuierliche Werte als Zeitreihen aufzuzeichnen. Die oben beschriebenen Ereignisse gehören nicht in diese Kategorie. Es ist zu prüfen ob das Monitoringsystem ggf. andere Wege anbietet solche Daten zu speichern oder unterschiedliche Datenquellen in einer gemeinsamen Ansicht zusammenfassen kann.
Eventuell ist es an dieser Stelle sogar nötig, unterschiedliche Software einzusetzen, um die unterschiedlichen Daten zu speichern. Dies ist aber nur sinnvoll, wenn es ein – ggf. 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-Lösung für Anwendungen gedacht. Aus Monitoringsicht kann man einen Container aber als eigenständige Rechner verstehen, mit CPU, Arbeitsspeicher, Mountpoints, mehreren Prozessen , Netzwerk, etc.
Klassischen Monitoring-Konzepte lassen sich aber nicht auf die Container anwenden. Ein Docker Container hat keinen eigenen SSH Server, es muss also ein Agent im Container installiert werden. Folglich würde dann in jedem Docker Container ein eigener Agent laufen. Damit wird das Image größer, der Build wird komplizierter und die Portabilität schwieriger. Das kann also nicht die Lösung sein.
Docker hat zur Lösung dieses Problems die stats-API zur Verfügung gestellt. Damit ist es möglich vom Docker Daemon Statistiken über alle Docker Container eines Hosts abzufragen. Somit wird es wieder möglich einen einzigen Agenten auf dem Host zu installieren und alle Informationen über diesen abzufragen. Die einzelnen Docker Container bleiben somit unberührt vom Monitoring. Es ist sogar möglich den Monitoring-Agenten in einem eigenen Docker Container zu betreiben:

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 Monitoringserver gesendet. Hat man aber mehrere Server und auch die gleichen Images auf unterschiedlichen Servern, möchte man noch wissen auf welchem Server der Container gerade läuft. Ansonsten sieht man im Monitoring ggf. ein Problem, kann aber nicht handeln, da nicht bekannt ist auf welchem Host gerade einer von möglicherweise hunderten gleichartigen Containern Probleme hat.
Für dieses Problem ist es sehr hilfreich, wenn das Monitoringsystem eine Möglichkeit anbietet, gesendete Daten mit Metainformationen anreichern zu lassen, darunter z. B. Hostname, Docker Imagename, etc. Dadurch erhalten die gesammelten Daten weiteren Kontext, der es ermöglicht auf Ereignisse zu reagieren. Wie diese zusätzlichen Daten den Messwerten zugeordnet werden, hängt stark vom eingesetzten Monitoringsystem ab.

Fazit

Mit diesem Artikel habe ich einige grundlegende Kriterien für das Monitoring einer Cloud aufgezeigt. Sie sollen bei der Auswahl eines konkreten Produktes helfen. Leider gibt es nicht die eine Lösung. Stattdessen muss für jede spezielle Cloud die jeweils geeignete Monitoringlösung gefunden werden. Hierbei kann es sein, dass die beste Lösung möglicherweise auch eine Kombination aus mehreren spezialisierten Monitoringsystemen sein kann.