Operations heute und morgen, Teil 5: Monitoring

Know-how  –  0 Kommentare

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.

Operations heute und morgen

Das Business scheint aus IT-Sicht seine Anforderungen und Wünsche nach neuen und aktualisierten Features immer schneller zu ändern. Gleichzeitig gibt es innerhalb der IT fortwährend neue Trends, die umgesetzt werden wollen. Doch wo steht der IT-Betrieb bei der Umsetzung der Anforderungen und Wünsche? Haben die Entwickler mit dem agilen Trend die Mauern zum Business eingerissen, kam in den letzten Jahren zunehmend der Wunsch nach DevOps auf. Dev steht für Development/Entwicklung und Ops für Operations/Betrieb. Damit soll auch die Mauer zwischen Entwicklung und Betrieb überwunden werden. Doch was hat sich bisher wirklich durchgesetzt? Das betrachtet die Artikelserie "Operations heute und morgen":

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.

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

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.