1Einleitung
Mit dem Begriff »Monitoring« werden Systeme bezeichnet, die den Zustand von Geräten und Programmen überwachen und beim Abweichen vom gewünschten Zustand Alarmmeldungen verschicken.1
Ohne Monitoring können die Betreuer von IT-Systemen nur dann reagieren, wenn ein Anwender eine Störung meldet oder sie selbst durch sehr zeitaufwendige manuelle Kontrolle oder per Zufall ein Problem feststellen. Beim heute üblichen Zahlenverhältnis zwischen Systemen und Betreuern ist eine manuelle Kontrolle nicht mehr zu realisieren und wenn ein Anwender ein Problem feststellt, ist es eigentlich schon zu spät, da genau diese Probleme ja verhindert werden sollen.
Um diese Problematik zu lösen, werden Monitoring-Systeme benötigt, die versuchen, Schwierigkeiten frühzeitig zu bemerken, damit sie behoben werden können, bevor sie größeren Schaden anrichten können oder bevor Benutzer davon betroffen sind. Dafür gibt es verschiedene Ansätze:
- Ermitteln von Ergebnissen einer eigenen Statusprüfung und Logs von Anwendungen oder Hardware.
- Ende-zu-Ende-Checks wie das Versenden einer E-Mail und Prüfen, ob sie auch ankommt.
- Simulieren einer Nutzung eines Dienstes wie das Aufrufen einer Website.
- Prüfen von Eckdaten eines Systems wie das Abfragen der Festplattenauslastung mit Bordmitteln.
Icinga 2 bietet dabei die Möglichkeit, alle oben genannten Verfahren abzudecken, spezialisiert sich jedoch auf die letzten beiden Ansätze. Diese Flexibilität rührt daher, dass Icinga 2 selbst keine Funktionalität zur direkten Überwachung enthält, aber sehr gut darin ist, »Plugins«, also ausführbare Dateien, die ein paar Anforderungen erfüllen, laufen zu lassen und die Ausgabe zu interpretieren. Falls sich also eine Überwachungsmöglichkeit in einer ausführbaren Datei realisieren lässt, kann sie auch in Icinga integriert werden.
1.1Es war einmal…
Icinga 2 ist ein sehr modernes Monitoring-System, das keinen Code von seinen geistigen Vorgängern enthält, aber fast alle bewährten Konzepte weiterverwendet. Diese Ähnlichkeit erleichtert vor allem Umsteigern die Arbeit mit Icinga 2 deutlich. Die folgenden Zeilen sollen einen kurzen Überblick über die bisherige Entwicklung geben.
1.1.1Icinga
Im April 2009 wurde das Icinga-Projekt gegründet, das einen Fork des Nagios-Monitoring-Systems entwickeln sollte, da viele Community-Mitglieder unglücklich über den Umgang mit eingereichten Patches und den Umgang von Nagios Enterprises mit der Nagios-Community waren. Bei einem Fork wird der aktuelle Stand des Quellcodes eines Programms von verschiedenen Entwicklerteams in unterschiedliche Richtungen weiterentwickelt. Häufig wird dabei das bisherige Team aufgespalten und je ein Teil entwickelt vom gleichen Ausgangspunkt aus in verschiedene Richtungen weiter. Üblicherweise behält dabei ein Team den Namen des Produkts bei und das andere sucht sich einen neuen. Beim Icinga-Team fiel die Wahl auf »Icinga«, das Zulu-Wort für »Ausschau halten«.
Der Fork, und damit auch die weiteren Schritte wie die Evolution von Icinga zu Icinga 2, war insbesondere auch möglich, da einige Firmen bereit waren, Entwicklern Zeit zu sponsern, um die Entwicklung von Icinga voranzutreiben. Dies geschah meist aus Eigeninteresse, da sie Monitoring auf Nagios-Basis bei sich oder ihren Kunden erfolgreich einsetzten und eine Lösung für die schleppende Entwicklung suchten. Der Fork war nötig, da zuvor zwar entwickelt wurde, die daraus resultierenden Patches jedoch nicht in Nagios einflossen. Das Icinga-Team bemüht sich, schneller auf Input aus der Community zu reagieren, und hat auch genug »Stammmitglieder«, um die Entwicklung voranzutreiben. Eine dieser Firmen ist die NETWAYS GmbH2 aus Nürnberg in Deutschland, die einige der Icinga-Kernentwickler angestellt hat, die entweder im Kundenauftrag oder als Dienst an der Community weiter an Icinga, Icinga 2 und anderen Tools aus diesem Ökosystem arbeiten. Auch die Autoren dieses Buchs haben von der NETWAYS GmbH Zeit gesponsert bekommen, um dieses Projekt zu verwirklichen.
1.1.2Icinga 2
Um einige sehr tief im Code verwurzelte Einschränkungen aufzulösen, hat sich das Icinga-Team entschlossen, mit dem Code bei null zu beginnen und alles komplett neu zu schreiben. Das Resultat ist das Release von Icinga 2 Version 2.0 vom 16. Juni 2014. Darin wurden die bekannten Konzepte in der Bedienung weitergeführt, aber auch einige sehr wichtige Neuerungen eingeführt.
Diese Neuerungen umfassen unter anderem:
- eine Domain Specific Language (DSL) zur Konfigurationi,
- den integrierten Cluster-Stack, zur Kommunikation von verschiedenen Icinga-Instanzen untereinander,
- das Verteilen von Teilen der Konfiguration an beliebig viele andere Icinga 2 Instanzen,
- besseres Ausnutzen der verfügbaren Ressourcen durch Multithreading,
- der Einsatz als Agent,
- die API, mit der u. a. zu überwachende Objekte zur Laufzeit hinzugefügt werden können.
Die neue regelbasierte Sprache erlaubt eine deutlich flexiblere Konfiguration. Viele Objekte, die früher einzeln definiert werden mussten, können nun automatisch durch Auswerten von Regeln und Funktionen angegeben werden. Das spart nicht nur sehr viel Tipparbeit, sondern schützt auch vor Fehlern, da einmal definierte Regeln natürlich auch für neue Objekte gelten.
Um Demilitarized Zones (DMZs) oder entfernte Netzwerke zu überwachen, wurden auch bei den Vorgängern von Icinga 2 schon mehrere Instanzen verwendet, die miteinander kommunizieren. Allerdings enthielten diese keinen nativen Weg, mehrere Instanzen miteinander zu verbinden, weshalb verschiedenste Lösungen dafür entwickelt wurden. Diese waren jedoch teilweise kompliziert zu konfigurieren und oft auch nicht performant genug, um die Zeit zwischen Auftreten einer Störung und der Alarmierung ausreichend kurz zu halten. Dieses Verbinden von Instanzen wurde auch genutzt, um die auftretende Last zwischen mehreren Hosts zu verteilen und in Verbindung mit Clustertools wie corosync3 und pacemaker4 Hochverfügbarkeit zu erreichen.
Durch die neue Clusterfunktionalität können nicht nur lastverteilte und hochverfügbare Cluster mit Icinga 2 Bordmitteln erreicht werden, auch untergeordnete Icinga 2 Instanzen in anderen Netzsegmenten können Ergebnisse von Checks, die sie ausführen, an zentrale Instanzen weiterschicken. Diese zeigen einen Gesamtüberblick an und alarmieren.
Über die Clusterverbindung kann auch von zentralen Systemen aus eine Konfiguration an untergeordnete Instanzen ausgebracht werden.
Die Vorgänger von Icinga 2 liefen als ein einziger Thread und konnten so auch nur einen CPU-Kern ausnutzen. Zwar waren die gestarteten Plugins immer schon eigene Threads, dennoch wurde dadurch einer Installation eine Obergrenze an zu überwachenden Systemen gesetzt. Icinga 2 ist nun multithreaded und kann die zur Verfügung stehenden Ressourcen tatsächlich ausnutzen.
Durch den geringen Ressourcenverbrauch des Icinga 2 Kerns, die Clusterverbindung und die Konfigurationsverteilung hat sich eine neue Anwendungsmöglichkeit als Agent ergeben. Dabei wird eine Icinga 2 Instanz auf einem zu überwachenden Host installiert, die nur eben diesen überwacht. Die Ergebnisse leitet sie über die Clusterverbindung an eine zentrale Instanz weiter, die die Checks aller angeschlossenen Icinga 2 Instanzen sammelt und eine Übersicht zur Verfügung stellt. Konfiguriert wird sie von der zentralen Instanz aus. Für einen Vergleich aus Anwendersicht bietet die Icinga 2 Onlinedokumentation5 einen umfassenden Überblick an.
1.1.3Namen und Versionen
Aktuell wird nur noch die Version 2.x weiterentwickelt. Dieses Buch behandelt ausschließlich den 2.x-Zweig der Entwicklung. Mit dem Versionssprung von 1.x auf 2.x geht aber auch eine Umbenennung einher, daher heißt das Tool nun tatsächlich »Icinga 2 Version 2.x«.
Gleiches gilt für das moderne Webinterface Icinga Web 2. Es ist übrigens zu beiden existierenden Icinga-Varianten kompatibel, weshalb man durchaus Icinga 2 2.8.1 wie auch Icinga 1.13.3 mit Icinga Web 2 2.5.1 betreiben kann.
Die hier genannten Versionen waren zum Zeitpunkt, als die zweite Auflage dieses Buchs entstand, die jeweils aktuellsten.
1.2Software-Komponenten
Ein Monitoring-System auf Basis von Icinga 2 besteht aus mehreren Teilkomponenten, so bildet der Core »Icinga 2« das Grundgerüst. Er regelt alle Abläufe, unter anderem z. B., wann was wie zu überwachen ist.
Die eigentliche Arbeit der Überwachung wird dann durch sogenannte Plugins erledigt, die vom Core aufgerufen werden und deren Ergebnisse...
