Die Open-Source-Gemeinde hat in den vergangenen Dekaden eine Vielzahl von leistungsfähigen Monitoringwerkzeugen hervorgebracht. Während die meisten Anbieter Freemium-Geschäftsmodelle verfolgen, beschreiten die Entwickler von Icinga einen anderen Weg: Ihr umfassendes Ökosystem lässt sich nahezu uneingeschränkt im Unternehmen einsetzen. Auch funktional lässt das Tool kaum Wünsche offen.
Die Überwachung kritischer Infrastrukturen ist ein Muss für jedes Unternehmen. Gerade in Zeiten digitaler Transformation wird die Funktionstüchtigkeit von Infrastrukturkomponenten immer bedeutsamer. Allerdings haben Unternehmen die Qual der Wahl, denn in jüngerer Zeit hat die Zahl an Monitoringumgebungen deutlich zugenommen. Doch viele dieser Werkzeuge tun im Grunde nichts anderes, als Metriken verschiedener Quellen einzulesen und auszuwerten. Damit unterscheiden sie sich nicht grundlegend von bekannten Spezialisten wie Nagios.
Dennoch stellt sich für Unternehmen die Frage, welches für den konkreten Anwendungs- und Anforderungskontext die optimale Software ist. Diese Frage lässt sich angesichts der Vielfalt der Überwachungsumgebungen nur schwer beantworten. Aus der Masse stechen immer wieder die Klassiker heraus, allen voran Checkmk, Nagios, OpenNMS und Zabbix. Zu dieser Gruppe zählt auch der Nagios-Fork Icinga [1], der sich seit seiner Loslösung im Jahr 2009 dank einer benutzerfreundlichen – wenn auch inzwischen antiquiert wirkenden – Weboberfläche und zusätzlichen Datenbank-Konnektoren für MySQL, Oracle und PostgreSQL etablieren konnte. Die Produktbezeichnung leitet sich aus der Sprache der Zulu, eine der größten Ethnien Südafrikas, ab und bedeutet so viel wie suchen beziehungsweise beobachten.
Für den Einsatz von Icinga sprechen verschiedene Argumente. Dank seiner langjährigen Entwicklungsphase darf das System als ausgereift gelten. Gleichwohl sind auch derlei Systeme nicht vor kritischen Sicherheitslücken gefeit: Im November 2024 vermeldeten die Entwickler eine kritische Schwachstelle, die das Ausführen beziehungsweise das Einschleusen kritischer Befehle erlaubte. Die Entwickler haben indes schnell mit Updates reagiert. Ein Pluspunkt ist sicherlich der Umstand, dass hierzulande an Icinga gefeilt wird.
Die Überwachung kritischer Infrastrukturen ist ein Muss für jedes Unternehmen. Gerade in Zeiten digitaler Transformation wird die Funktionstüchtigkeit von Infrastrukturkomponenten immer bedeutsamer. Allerdings haben Unternehmen die Qual der Wahl, denn in jüngerer Zeit hat die Zahl an Monitoringumgebungen deutlich zugenommen. Doch viele dieser Werkzeuge tun im Grunde nichts anderes, als Metriken verschiedener Quellen einzulesen und auszuwerten. Damit unterscheiden sie sich nicht grundlegend von bekannten Spezialisten wie Nagios.
Dennoch stellt sich für Unternehmen die Frage, welches für den konkreten Anwendungs- und Anforderungskontext die optimale Software ist. Diese Frage lässt sich angesichts der Vielfalt der Überwachungsumgebungen nur schwer beantworten. Aus der Masse stechen immer wieder die Klassiker heraus, allen voran Checkmk, Nagios, OpenNMS und Zabbix. Zu dieser Gruppe zählt auch der Nagios-Fork Icinga [1], der sich seit seiner Loslösung im Jahr 2009 dank einer benutzerfreundlichen – wenn auch inzwischen antiquiert wirkenden – Weboberfläche und zusätzlichen Datenbank-Konnektoren für MySQL, Oracle und PostgreSQL etablieren konnte. Die Produktbezeichnung leitet sich aus der Sprache der Zulu, eine der größten Ethnien Südafrikas, ab und bedeutet so viel wie suchen beziehungsweise beobachten.
Für den Einsatz von Icinga sprechen verschiedene Argumente. Dank seiner langjährigen Entwicklungsphase darf das System als ausgereift gelten. Gleichwohl sind auch derlei Systeme nicht vor kritischen Sicherheitslücken gefeit: Im November 2024 vermeldeten die Entwickler eine kritische Schwachstelle, die das Ausführen beziehungsweise das Einschleusen kritischer Befehle erlaubte. Die Entwickler haben indes schnell mit Updates reagiert. Ein Pluspunkt ist sicherlich der Umstand, dass hierzulande an Icinga gefeilt wird.
Erste Schritte
Das Herzstück der Icinga-Umgebung ist der Überwachungsserver "Icinga 2", der die Überwachungsaufgaben verwaltet, Überprüfungen durchführt und bei Bedarf Alarme versendet. Der Server wird mit "Icinga Web 2" gesteuert, während der "Icinga Director" für die Konfiguration zuständig ist. Alternativ können Sie auch zu Icinga DSL (Domain Specific Language) für die textbasierte Konfiguration greifen.
Ein einzelner Icinga-Server kann bereits eine Vielzahl von Infrastrukturkomponenten überwachen. Da Icinga über einen integrierten Cluster-Mechanismus verfügt, können Sie die Last bei komplexen und verteilten Umgebungen auf mehrere Schultern verteilen. Die Bündelung von zwei Icinga-Servern in einer Zone ist auch aus der HA-Perspektive sinnvoll. So sind Sie auch beim Ausfall eines Systems sicher, dass die Infrastruktur weiterhin überwacht wird. Ein weiterer Pluspunkt: Bei einem sehr hohen Monitoringaufkommen können Sie über zusätzliche Knoten die Last verteilen. In der Icinga-Terminologien nennt sich dieses Feature "Satellite".
Zu einer vollständigen Installation gehören neben "Icinga 2" folgende Komponenten: "Icinga DB", "Icinga Web", "Icinga DB Web" und "Icinga Director". Außerdem bedarf es einer Datenbank für die gesammelten Daten, vorzugsweise MySQL neuer als 5.7 oder MariaDB neuer als 10.2. Nach dem Hinzufügen des Icinga-Repositories müssen Sie die verschiedenen Pakete installieren. Das gelingt unter Debian und Ubuntu einfach mit folgenden Kommandos:
apt install \ icinga2 \
icingacli \
icingadb \
icingadb-redis \
icingadb-web \
icingaweb2 \
icinga-director \
monitoring-plugins
Mit dem Installations-Skript "icinga-installer" [2] aus dem Web geht es einfacher. Allerdings basiert dieses Skript auf Puppet und verlangt eine entsprechende Installation, der Versionsstand muss hier zwischen 7.9.0 und 9 liegen. Alternativ greifen Sie auf einen Docker-Container [3] zurück.
Nach der Installation wartet der webbasierte Einrichtungsassistent auf Sie. Im ersten Dialog geben Sie das Setup-Token ein, das Sie mit folgendem Befehl generieren:
icingacli setup token show
Es folgt die Modulauswahl. Hier können Sie neben den Kernkomponenten beispielsweise die Dokumentation oder das Incubator-Modul installieren. Im Folgedialog listet der Assistent die Systemanforderungen auf. Erfüllte werden grün, optionale Anforderungen gelb markiert. Es folgen die Auswahl des Authentifizierungstyps und die Datenbankkonfiguration.
Bild 1: Das Icinga-Setup führt Sie durch die notwendigen Einrichtungsschritte samt Auswahl der gewünschten Module.
Da Icinga mehrere Backends unterstützt, müssen Sie die genaue Bezeichnung angeben. Es folgen das Einrichten des administrativen Accounts und der Applikationen. Sie können beispielsweise den Logging-Typ und das Logging-Level anpassen. Anhand einer Zusammenfassung prüfen Sie Ihre Einstellungen noch einmal.
Im nächsten Schritt konfigurieren Sie das Modul "Icinga DB Web". Es ist für die Visualisierung von Daten verantwortlich, die in "Icinga DB" gespeichert sind. Auch hier folgt eine abschließende Prüfung der gewählten Einstellungen. Damit ist die Umgebung einsatzbereit.
Einstieg ins Monitoring
Mithilfe von "Icinga 2" überwachen Sie die Verfügbarkeit von Hosts und Services. Dabei kann es sich um nahezu beliebige Objekte handeln, die auf die eine oder andere Art überprüfbar sind. Typische Objekte sind folgende:
- Netzwerkdienste (HTTP, SMTP, SNMP, SSH et cetera)
- Drucker
- Switches oder Router
- Temperatursensoren
- Weitere lokale oder über das Netzwerk zugängliche Dienste
Das Monitoring vereinfacht sich durch einen simplen, aber wirkungsvollen Ansatz: Sie können Dienste gruppieren, die auf demselben physischen Gerät laufen. Dabei leistet Ihnen die "Icinga Template Library" (ITL) wertvolle Dienste, denn sie implementiert Standardvorlagen und Objektdefinitionen. Ein einfaches Beispiel für ein Host-Objekt mit zwei untergeordneten Services sieht wie folgt aus:
object Host "server" {
address = "192.168.1.1"
check_command = "hostalive"
}
object Service "ping4" {
host_name = "server"
check_command = "ping4"
}
object Service "http" {
host_name = "server"
check_command = "http"
}
Vorangehendes Beispiel generiert zwei Dienste namens "ping4" und "http", die zu dem Host "server" gehören. Mit dem hostalive-Check fragen Sie die Verfügbarkeit des Hosts ab. Das Attribut "address" spezifiziert, welche Netzwerkadresse mit dem Host-Objekt verbunden ist.
Beim Abfragen von Services generiert Icinga folgende Statusmeldungen: "OK", "WARNING", "CRITICAL" und "UNKNOWN". Die Check-Plug-ins geben einen Exit-Code zurück, der in eine Statusnummer konvertiert wird; anschließend folgt die Zuordnung zu einem Host- beziehungsweise Dienststatus. Wenn Sie identische Attribute auf mehrere Objekte anwenden wollen, greifen Sie zur Template-Funktion. Hier ein Beispiel für eine solche Vorlage:
template Service "generic-service" {
max_check_attempts = 3
check_interval = 5m
retry_interval = 1m
enable_perfdata = true
}
apply Service "ping4" {
import "generic-service"
check_command = "ping4"
assign where host.address
}
apply Service "ping6" {
import "generic-service"
check_command = "ping6"
assign where host.address6
}
In diesem Beispiel erben die Dienste "ping4" und "ping6" die Eigenschaften der Vorlage "generic-service". Grundsätzlich können Objekte und Vorlagen beliebig viele bereits existierende Vorlagen importieren. Ein weiteres mächtiges Werkzeug sind die Makros. Damit greifen Sie zur Laufzeit auf Attribute und benutzerdefinierte Variablen von Objekten zu.
Konfiguration per Icinga Director
Nach der Inbetriebnahme von Icinga verrät Ihnen das Dashboard der Monitoringumgebung, wie es um den Zustand Ihrer Infrastruktur bestellt ist. Damit das System erste Daten sammelt, müssen Sie Hosts und Services anlegen. Für diese Konfiguration stehen Ihnen zwei Werkzeuge zur Verfügung: Sie können das Monitoring mit Icinga auf der Konsolenebene mit "Icinga DSL" oder mit dem grafischen Werkzeug "Icinga Director" konfigurieren. Bei beiden handelt es sich um webbasierte Instrumente. Mithilfe des Director-Moduls gehen typische Aufgaben leicht von der Hand. Es dient der Definition von Hosts, Diensten und anderen Überwachungsobjekten. Sie können das Modul zudem in verschiedene Datenquellen integrieren, sodass sich Ihre Überwachung einfacher mit Ihrer Infrastruktur synchronisieren lässt.
Bild 2: Das Dashboard verrät, wie es um den Zustand Ihrer Infrastruktur bestellt ist.Bild 3: Der Icinga Director ist ein nützliches Werkzeug für die Konfiguration der Monitoringumgebung.
Um den Director zu konfigurieren, generieren Sie im Administrator-Konto über "Configuration / Application / Resources" eine neue Datenbankressource für die Icinga-Director-Datenbank. Die Ressource definiert die Verbindungsdetails für die Datenbank. Mittels des Director-Moduls automatisieren Sie dann auch die Monitoringprozesse.
Grundsätzlich können Sie die zu überwachenden Hosts auch manuell oder mit einem Tool wie Ansible generieren. Welchen Weg Sie dabei einschlagen, ist auch von den individuellen Präferenzen abhängig.
In der Praxis hat es sich bewährt, Gruppen mit ähnlichen Services zu formen. Außerdem gilt es zu klären, wer mit Alarmen versorgt wird. Die Logik der Anwendungsregeln bietet vielfältige Möglichkeiten, das Monitoring zu optimieren. Das Ziel muss es sein, eine Überwachungslogik zu entwickeln, die nicht auf Host- oder Service-Ebene basiert. Der Director ist das Instrument der Wahl, wenn Sie mit verteilten Umgebungen arbeiten und dabei auf Tools wie Puppet oder Ansible setzen.
Die Anwendung gestaltet sich einfach. Über das Menü "Icinga Director" legen Sie mit "Host objects" beziehungsweise "Monitored Services" die zu überwachenden Hosts und Dienste an. Das Prozedere: Sie öffnen die Host- oder Service-Konfiguration, schaffen ein neues Objekt und weisen diesem die gewünschten Einstellungen zu. Dazu klicken Sie in der Host-Verwaltung auf das Pluszeichen und spezifizieren das Host-Template.
Außerdem geben Sie den Hostnamen sowie die IP-Adresse an und weisen diese einer Gruppe zu. Mit den benutzerdefinierten Einstellungen ("Custom properties") bestimmen Sie den Umgebungstyp (Entwicklung, Produktion oder Testung) und das Betriebssystem. Bei verteilten Umgebungen spezifizieren Sie den Standort. Kommt auf dem zu überwachenden System ein Agent zum Einsatz, müssen Sie die Verbindungsdaten angeben.
Das Anlegen von Services verläuft nach dem gleichen Schema. Um einen einzelnen Service aus der Taufe zu heben, wechseln Sie in das gleichnamige Untermenü und folgen dem Link "Single Services". Auch hier wählen Sie wieder das Template aus oder erzeugen eine neue Vorlage. Neben der Host-Auswahl steht Ihnen eine Fülle an benutzerdefinierten Prüfoptionen zur Verfügung.
Auch das Schaffen von Prüf-Sets ist möglich. Der Director verrät Ihnen außerdem über das Untermenü "Notifications", welche Benachrichtigungen per E-Mail oder SMS auf den Weg gebracht wurden. Nicht zuletzt können Sie hier die Logfiles einsehen.
Ein Manko von Icinga ist sicherlich, dass es nicht in der Lage ist, Hosts und Services automatisch zu erkennen. Gleichwohl gibt es auch für diese Herausforderung Lösungen. In der Regel bedient sich Admins dazu Configuration-Management-Werkzeugen, die über spezielle Module Icinga integrieren, beispielsweise für Puppet [4] oder Chef [5].
Mit Agenten arbeiten
Sind bestimme Remote-Dienste nicht über das Netz zugänglich, bietet sich die lokale Installation von Agenten an, um die relevante Host- und Service-Informationen auszulesen. Icinga-Agenten sind für Linux- und Windows-Systeme verfügbar. Die gewonnenen Informationen werden nahtlos in den Monitoring-Stack übernommen. Das Zusammenspiel von Überwachungsserver und Agent ist so konzipiert, dass beide Seiten eine Verbindung zur Gegenseite aufbauen können. Sobald diese steht, tauschen sie die Prüfergebnisse aus.
Bild 4: Die Konfiguration der Icinga-Agenten für Windows gestaltet sich einfach.
Die Nutzung ist einfach: Über das Icinga Package Repository [6] stehen die Installationspakete der Agenten für die unterstützten Plattformen zur Verfügung. Zur Konfiguration bedarf es lediglich der Daten des Master-Servers und gegebenenfalls der Zone.
Für Systeme, für die es keinen Icinga-Agenten gibt, sei es aufgrund spezifischer Hardwarearchitekturen oder weil die Installation zusätzlicher Software nicht zulässig ist, bietet sich die Verwendung des SSH-Dienstes auf dem Remote-Host an. Für die Kommunikation mit dem Icinga-Server ist das Plug-in "check_by_ssh" zuständig. Es ist Teil des Pakets "Monitoring Plugins". Die Icinga-Template-Bibliothek stellt bereits das Kommando "by_ssh" bereit.
Anstelle des Icinga-Agenten können Sie auch zu NSClient++ [7] greifen. Dieser Monitoringclient wurde ursprünglich für Nagios entwickelt, spielt aber auch hervorragend mit dessen Forks zusammen. Der NSClient++-Agent ist insbesondere für seine umfängliche Windows-Unterstützung bekannt.
Auch Clouds überwachen
In Zeiten, in denen immer mehr Firmen ihre IT in die Cloud auslagern, rückt das Monitoring vom Cloudumgebungen in den Fokus. Auch für diesen Aufgabenbereich ist Icinga gerüstet, denn grundsätzlich macht es für das Werkzeug keinen Unterschied, ob Sie auf eine lokale oder eine cloudbasierte Umgebung setzen. Sie können private Clouds auf Basis von VMware oder OpenStack genauso überwachen wie öffentliche Clouds, die auf AWS, Microsoft Azure und der Google Cloud Platform basieren. Spezielle Module für vSphere und AWS befriedigen spezifische Informationsanforderungen. Icinga kann insbesondere cloudnative Metriken wie IOPS, API-Anforderungsgrenzen und Netzwerkdurchsatz verarbeiten. Und: Die Icinga-Agenten auf VMs verhalten sich genauso wie auf physischen Servern.
Abos und mehr
In der Welt der Freemium-Angebote unterscheidet sich Icinga grundlegend von vielen anderen Offerten. Die Open-Source-Variante umfasst sämtliche Softwarefunktionen. Admins kommen also in den Genuss der vollen Funktionalität der Überwachungsumgebung. Gleichwohl offerieren die Entwickler verschiedene Abonnements mit Zusatzfunktionen und -dienstleistungen [8]. Das Icinga-Repository-Abonnement etwa erlaubt den Zugriff auf Erweiterungen. Diese umfassen "Icinga Director Branches" und Support. Hier unterscheidet der Anbieter zwischen Basic-, Premium- und Enterprise-Plänen. Preise verrät die Website nicht, vielmehr ist die Kontaktaufnahme zum Sales-Team erforderlich. Das haben wir gemacht; die angekündigte Kontaktaufnahme durch einen lokalen Ansprechpartner blieb jedoch bis zum Redaktionsschluss aus.
Flexibilität durch Module
Das Icinga-Ökosystem zeichnet sich durch eine breite Palette an Komponenten aus, die das modulare System um Zusatzfunktionen erweitern. Die Module lassen sich üblicherweise im Standardpfad "/usr/share/icingaweb2/modules" installieren. Eine dieser Komponenten ist "Icinga Cube". Dieses Modul verzahnt sich mit dem Dashboard und versorgt Sie mit verschiedenen Host- und Service-Statistiken. Es ist insbesondere dazu geeignet, sich einen Überblick über die Infrastruktur zu verschaffen und verrät Ihnen beispielsweise, wie viele Server an den verschiedenen Standorten überwacht werden und wie es um deren Auslastung bestellt ist. Damit ist es insbesondere für jene Nutzer geeignet, die einen weniger technischen Blick auf den Infrastrukturzustand wünschen.
Ferner erlaubt das Modul "Icinga Business Process Modeling" das Visualisieren der hierarchische Geschäftsprozesse auf der Grundlage von Objekten. Dazu können Sie eigene prozessbasierte Dashboards generieren, die etwa Benachrichtigungen auf Prozess- oder Unterprozessebene auslösen. Dieses Modul bietet eine Art Vogelperspektive auf die Infrastruktur. Die Darstellung lässt sich dabei gezielt einschränken. Konkret können Sie beispielsweise das Überwachungsrauschen deaktivieren, das durch Skalierungsmechanismen generiert wird. Die Modelling-Funktion ist über die Menüleiste des Webinterface verfügbar.
Icinga ist auch für die Integration von bestehenden Cloudumgebungen gerüstet. Das Modul "Icinga vSphere Integration" erlaubt beispielsweise das Einbetten von VMwares Virtualisierungsplattformen. Mit "Icingabeat" steht ein Werkzeug bereit, das über das Icinga-API gesammelte Daten an Elasticsearch- oder Logstash-Installationen transferiert. Dabei überwacht die Monitoringumgebung einen Event-Stream, der detaillierte Informationen über Ereignisse wie beispielweise Prüfergebnisse, Benachrichtigungen, Ausfallzeiten, Bestätigungen et cetera umfasst. Aus der Eventstream-Analyse ergeben sich Hinweise bezüglich etwaiger Engpässe bei der Ausführungszeit und Latenz von Serviceprüfungen.
Nicht minder interessant ist das Modul "Icinga for Kubernetes". Damit können Sie Google-Container-Verwaltungen in das Monitoring integrieren. Über die Kubernetes-API verschafft sich Icinga Zugriff auf die relevanten Daten. Das Modul "Icinga for Kubernetes Web" sorgt für die Visualisierung der Kubernetes-Ressourcen. Allerdings unterliegt die Funktion einer Einschränkung: Bislang lässt sich lediglich ein Kubernetes-Cluster pro Icinga-for-Kubernetes-Installation überwachen.
Für Abo-Kunden steht mit "Icinga Director Branches" ein weiteres Modul zur Verfügung. Dieses Add-on erlaubt das Anlegen von verschiedenen Konfigurationszweigen im Director-Modul. So lassen sich nutzerspezifische Monitoringkonfigurationen implementieren. Die Entwickler sprechen in diesem Kontext von "Parallelrealitäten".
Auf der Roadmap
Was die Verbesserung von Icinga betrifft, sind die Entwickler aktuell dabei, die Benachrichtigungsfunktion zu überarbeiten. Notifications lassen sich bislang spezifischen Hosts, Dienste, Kontakten und Kontaktgruppen zuweisen. Die neue Benachrichtigungszentrale unterstützt nicht nur die Verwendung von "Icinga 2" als Benachrichtigungsquelle, sondern auch andere Module wie "Business Process Modeling", "Icinga Director" oder "Certificate Monitoring". Neuerung gibt es auch im Hinblick auf das Monitoring von Kubernetes-Umgebungen. Da diese sich anders als herkömmliche IT-Infrastrukturen verhalten, ist ein dediziertes Programm in Arbeit, das sich innerhalb oder außerhalb eines Kubernetes-Clusters ausführen lässt, aber jede Änderung und jeden Fehler innerhalb des Clusters registriert. Die entsprechenden Informationen sollen in Zukunft über das Dashboard zugänglich sein.
Fazit
Wenn es ums Monitoring geht, macht Icinga einen ausgezeichneten Job. Die Konfiguration der Umgebungen gestaltet sich einfach, wenngleich ein integrierter Autodetect-Mechanismus wünschenswert wäre, um nicht auf Drittanwendungen angewiesen zu sein. Das Webinterface ist ein wenig in Jahre gekommen, doch das tut der gelungenen Überwachungsarbeit des Spezialisten keinen Abbruch.