Operations heute und morgen, Teil 5: Monitoring

Seite 2: Anforderungen

Inhaltsverzeichnis

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.

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.

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).

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.