Im ersten Teil dieser zweiteiligen Blogserie wurden die grundlegenden Punkte zur unterschiedlichen Architektur von Software, sowie die Vorteile von Microservices gegenüber Monolithen dargelegt.

Das Leben der srv-01, -02 oder -03 ist nichts mehr wert – es lebe „n“!

Wenn abzusehen ist, dass sich die Applikationen und Workloads des Unternehmens zukünftig in dynamische Umgebungen oder agile Cloud-Infrastrukturen verschieben, egal ob extern gehosted oder „on-premises“, dann sollte auch das Monitoring dahingehend angepasst werden.

In dynamischen Umgebungen, wo virtuelle Systeme je nach Notwendigkeit und Last automatisch geboren und wieder abberufen werden, steht auch bei dem Monitoring nicht mehr das einzelne System im Vordergrund, sondern viel eher, ob der übergeordnete Dienst aus Nutzersicht funktioniert und selbiger die versprochene Leistung abrufen kann. Im Fokus des Monitoring-Systems stehen somit Korrelationen und Aggregationen!

Die Basis für diese in Beziehung gestellten Merkmale, Ereignisse und Zustände müssen aber keine reinen Status-Checks sein. Auch die von Metrik-Checks ermittelten Werte können extrapoliert und über entsprechende Regeln in Beziehung zueinander gestellt werden. Auf Basis dieser können später Aussagen getroffen und dementsprechend gesteuert werden, ob die Ampel auf dem Bildschirm des Managers grün oder rot leuchtet.

Das am häufigsten eingesetzte Monitoring-Tool ist vermutlich nach wie vor Nagios – oder eines aus seiner Abstammung entstandenen und angepassten Klone (Forks).

Auf dem Markt gibt es heute aber eine Vielzahl an Monitoring-Tools. Die am häufigsten eingesetzten freien Lösungen sind in unserem „Open Source Monitoring Guide“ beleuchtet und die jeweiligen Stärken herausgestellt. Je nach Anwendungsfall, Anforderungen und den gelebten Prozessen des Unternehmens, muss eine Abwägung stattfinden.

Welches Tool aber ist die Lösung für unser beschriebenes Szenario? Unsere Empfehlung: Sensu

 

Warum man man seine Nagios-Umgebung jetzt auf Sensu migrieren sollte!

1. Sensu ist kompatibel zu den Nagios-Plugins. Dadurch ist es möglich, bisherige Prüfungen zu übernehmen. Der Reifegrad des Monitorings bleibt somit erhalten. Durch die Verwendung zusätzlicher sensu-eigener Status- und Metrik-Plugins, kann das bestehende Monitoring sogar erweitert und Mehrwerte geschaffen werden.

2. Durch die „Microservices“-Architektur von Sensu lässt sich die Monitoring-Umgebung sehr gut skalieren. Anders als bei „schwerfälligen“ Monolithen, wo die einzige Möglichkeit zur Leistungssteigerung oftmals nur ist, dem verantwortlichen System mehr Ressourcen zur Verfügung zu stellen.

3. Sensu erzeugt durch seine intelligente Architektur eine geringere Last. In der Regel beherbergt das Monitoring-System durchschnittlich eine Anzahl von 30-50 unterschiedlichen (!) Checks. Die Masse der Prüfungen ist jedoch für jedes System oder eine Gruppe von Systemen (Windows-Server, Linux-Server, Router, Switche) identisch. Wird bei Nagios jeder einzelne Check separat geplant und ausgeführt, so kann dies bei Sensu auf zwei unterschiedliche Arten geschehen, welche beide deutlich ressourcensparender agieren:

Möglichkeit eins ist die Verwendung der sogenannten Publish/Subscribe (Pub/Sub) Methode. Hierbei werden Checks mit passenden Schlagworten versehen und somit gruppiert. Prüfungen, welche bspw. von allen Windows-Servern ausgeführt werden sollen, erhalten so bspw. das Schlagwort „windows“, Webserver-Prüfungen das Schlagwort „webserver“, usw. Gibt der Sensu Server diese Checks „in Auftrag“, führen alle Server die zu ihren Schlagworten passenden Checks aus und übermitteln die Ergebnisse zurück. Jede definierte Prüfung muss pro Intervall also nur einmal getriggert werden, löst durch die Zugehörigkeiten aber bspw. auf allen 1000 Servern einen Check aus. Da in der Regel auch die Intervalle je Art eines Checks identisch sind und kein Administrator den CPU-Checks individuell für jedes System separat einplant, kann man hier getrost auf die pauschale Konfiguration zurückgreifen.

Bei der zweiten Möglichkeit liegen die Aufgaben des Einplanens und Ausführens der Prüfungen komplett auf der Seite des Sensu Clients, also dem überwachten System. Dies sind die sogenannten „Standalone Checks“. In diesem Fall hat der Sensu Server nur noch die ankommenden Ergebnisse zu verarbeiten und braucht sich nicht einmal mehr um das Einplanen und Ausführen der Checks zu kümmern.

Egal welche Methode zum Einsatz kommt, die erzeugte Last des Sensu Server ist aufgrund dieser Architektur deutlich geringer. Existieren komplexere Anforderungen, können auch beide Methoden in Kombination eingesetzt werden.

4. Mit Sensu kommen Automatisierungskripte der wesentlichen SCM-Tools frei Haus. Die „directory-based configuration“ macht es sehr einfach, sein Monitoring mittels Automatisierungswerkzeugen, wie Ansible, Chef, Puppet oder SaltStack zu betreuen. Werden durch diese Werkzeuge neue Tools oder Dienste auf zu überwachenden Servern ausgerollt, kann ganz einfach die dazu passende Prüfung als Datei im JSON-Format mit ausgerollt und in dem Sensu Ordner abgelegt werden. Nach einem Neustart des Sensu Clients wird auch der soeben erst ausgerollte neue Dienst mit überwacht.

5. Sensu bietet bereits heute sehr viele Integrationsmöglichkeiten. So bringt der Sensu Server, sowie  auch die Sensu Clients eine API mit. An die API des Sensu Servers dockt sich bspw. das Dashboard zur Darstellung der in Sensu enthaltenen Geräte und Services an. Zur API der Sensu Clients können bspw. Prüfergebnisse übermittelt werden. Beispiele für Anbindungen sind zudem das Speichern der ermittelten Daten in Graphite zur Darstellung der Metriken in Grafana, oder das Senden von Benachrichtigungen zu Slack, IRC oder Hipchat. Weitere Integrationen sind: InfluxDB, Graylog, JIRA, DataDog, Chef, Librato, Puppet, Pagerduty, OpenTSDB, SNMP, ServiceNow, Wavefront, uvm.

6. Zeitpunkt und Lösung strategisch perfekt. Mit Sensu kann man seine „alte Welt“ in die „neue Welt“ migrieren, ohne dabei alles umwerfen zu müssen. Selbstgeschriebene Plugins können übernommen werden, oder ein Mehrwert geschaffen werden, sollten existierende Plugins gehaltvollere Informationen liefern. Mit einer Migration von Nagios zu Sensu kann also ein sanfter Übergang mit bestehenden Prüfungen in eine neue Architektur vollzogen werden. Außerdem verliert man nicht die große Vielfalt der Community-Plugins aus der Welt von Nagios. Zudem profitiert man durch eine geringere Last und die Flexibilität, die Sensu bietet. Man profitiert also von den Vorteilen beider Tools.

Zuletzt muss man sich Gedanken darüber machen, wie eine Übernahme des bestehenden Monitorings vollzogen werden kann. Migrationen werden oft von Migrations-Skripten erledigt, um den Zeitraum zu minimieren und den Bestand möglichst 1:1 zu übernehmen. In vielen Bereichen ist das wohl auch eine gute Sache. Im Bereich des Monitorings kann man so einen Zeitpunkt aber auch sehr gut dazu nutzen, seinen über Jahre angewachsenen Bestand des Monitoring aufzuräumen und z. B. bestehende Check-Definitionen und Skripte zu überarbeiten und durch neuere, performantere und gehaltvollere Plugins zu ersetzen.