Betrieb & Monitoring
Icinga
Icinga ist ein quelloffenes Monitoring-System (Nagios-Fork); Icinga 2 ist eine C++-Neuimplementierung, Nagios-Plugin-kompatibel, mit verteiltem Monitoring.
- Nagios-Fork, Icinga 2 neu in C++
- Verteiltes Monitoring (Zonen)
- REST-API und Icinga Director
- Nagios-Plugin-kompatibel
- Open Source (GPL)
Icinga entstand 2009 als Fork von Nagios, weil dessen Entwicklung damals stockte. Mit Icinga 2 folgte eine vollständige Neuimplementierung in C++, die keinen Nagios-Code mehr teilt, dessen Plugin-Schnittstelle aber bewusst beibehält: Jedes bestehende Nagios-Plugin funktioniert weiter. Dazu kommen ein modernes, objektbasiertes Konfigurationsmodell, eine REST-API und natives verteiltes Monitoring.
Dieser Artikel erklärt den Core und die Nagios-Plugin-Kompatibilität, die Konfigurations-DSL mit Templates und apply-Regeln, das Master/Satellite/Agent-Zonenmodell samt HA, den Wechsel vom älteren IDO zur Icinga DB, den grafischen Icinga Director, die REST-API und Betriebskonzepte wie Downtimes und Flap Detection. Eine sachliche Einordnung gegenüber Zabbix gehört dazu.
1. Core und Nagios-Plugin-Kompatibilität
Icinga 2 ist eine Neuimplementierung in C++ und teilt keinen Code mit Nagios, bildet aber dessen Plugin-Interface nach. Bestehende Nagios- und Icinga-Plugins laufen daher in der Regel unverändert weiter; sie kommunizieren über standardisierte Exit-Codes (0 = OK, 1 = Warning, 2 = Critical, 3 = Unknown) und ein Performance-Data-Format. Quellen sind das Monitoring-Plugins-Projekt, die Icinga Template Library (ITL) und selbst geschriebene Checks in Bash, Python, Perl oder Go.
2. Konfiguration: DSL, Templates und apply
Icinga 2 wird in einer eigenen DSL (Domain Specific Language) konfiguriert. Objekte werden mit object definiert, erben Attribute über import aus Templates und werden über apply-Regeln dynamisch erzeugt (etwa „weise diesen Service jedem Host zu, auf den eine Bedingung passt“). Die DSL kennt Variablen, Bedingungen, Schleifen und Funktionen, was sie mächtig, aber auch lernintensiv macht.
Icinga-2-DSL: Ping-Service per apply-Regel auf alle Linux-Hosts
apply Service "ping4" {
import "generic-service"
check_command = "ping4"
assign where host.address && host.vars.os == "Linux"
}3. Verteiltes Monitoring im Zonenmodell
Icinga 2 organisiert verteilte Aufbauten in Zonen mit einer Eltern-Kind-Hierarchie aus drei Rollen: Master (oberste Ebene, hostet Icinga Web), Satellite (mittlere Ebene, führt Checks aus oder delegiert) und Agent (unterste Ebene, lokale Checks). Sicherheit basiert auf explizitem Vertrauen: Kind-Zonen dürfen keine Konfiguration an Eltern-Zonen senden. Hochverfügbarkeit entsteht durch zwei Knoten in derselben Zone, die Cluster-Events replizieren.
- Command Endpoint der Master steuert den Agent über die API; auf dem Agent ist keine eigene Konfiguration nötig.
- Config Sync der Master synchronisiert Konfigurationsdateien an Satellite/Agent, die dann lokal Checks ausführen.
4. Datenbank-Backend: IDO und Icinga DB
Das ältere IDO (Icinga Data Output) exportiert Konfiguration und Status nach MySQL/PostgreSQL, ist aber als veraltet markiert und soll in einer kommenden Version entfallen. Nachfolger ist Icinga DB: Icinga 2 schreibt volatile Daten in einen Redis-Server, ein Daemon übernimmt sie in eine relationale Datenbank, und Icinga DB Web liest aktuelle Zustände schnell aus Redis und Historisches aus der SQL-Datenbank. Das trennt schnellen Live-Zustand von dauerhafter Speicherung.
5. Icinga Director, REST-API und Betrieb
Wer nicht in der DSL arbeiten möchte, nutzt den Icinga Director, ein Web-Modul mit grafischer Konfiguration, Audit-Log, Berechtigungen und Import/Sync aus CMDBs. Die REST-API (Port 5665, TLS, Authentifizierung per Basic Auth oder Client-Zertifikat) erlaubt CRUD auf Objekte, das Auslösen von Aktionen und Live-Streaming von Ereignissen. Im Betrieb gibt es Downtimes (geplante Wartung), Acknowledgements (Quittieren) und Flap Detection gegen flatternde Zustände. Für Graphen werden Graphite/InfluxDB plus Grafana angebunden.
Die Stärke von Icinga ist die Kombination aus Nagios-Kompatibilität und nativem, sicherem Zonenmodell. Der Preis dafür ist ein mehrteiliger Stack und eine DSL, die man beherrschen muss; wer beides nicht will, fährt mit einem all-in-one-Werkzeug einfacher.
6. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Volle Nagios-Plugin-Kompatibilität, riesiges Plugin-Ökosystem | DSL-Konfiguration mit spürbarer Lernkurve |
| Natives verteiltes Monitoring mit Zonen und HA | Mehrteiliger Stack (Core, Web, Icinga DB, Redis, SQL, Director) |
| REST-API nativ integriert (CRUD, Aktionen, Events) | IDO-Ablösung erfordert Migration zu Icinga DB |
| Icinga Director für GUI-Konfiguration und CMDB-Sync | Visualisierung erst über Grafana/Graphite/InfluxDB |
| Open Source (GPL), aktiv gepflegt aus Deutschland | Keine eigene Zeitreihen-DB; Metrik-Backend extern |
Häufige Fragen zu Icinga
Ja, das ist ein Kernmerkmal. Icinga 2 implementiert die Nagios-Plugin-Schnittstelle vollständig; bestehende Plugins laufen ohne Änderung. Das macht Icinga zum naheliegenden Migrationsweg für Teams aus der Nagios-Welt.
Beides sind Datenbank-Backends. IDO ist das ältere, schreibt direkt in MySQL/PostgreSQL und wird abgekündigt. Icinga DB ist der Nachfolger mit Redis für schnellen Live-Zustand und SQL für Historie; neue Installationen sollten direkt Icinga DB verwenden.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Icinga im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.