Nagios / Icinga
Nagios ist das Urgestein der Monitoring-Tools. Ende der 1990er als „NetSaint" gestartet, 2002 in Nagios umbenannt, ist es bis heute der konzeptionelle Vorfahre fast aller Mitbewerber. Icinga ist ein 2009 entstandener Fork mit moderner Codebase, Web-UI und Konfiguration – Nagios-kompatibel, sodass dessen riesiges Plugin-Ökosystem weiter nutzbar bleibt. Wenn du in der Prüfung „Nagios/Icinga" liest, geht es immer um dieselbe Idee: ein schwellenwertbasiertes Monitoring, das per Plugins (kleine externe Programme) prüft, ob ein Service in Ordnung ist – mit den vier festen Zuständen OK, WARNING, CRITICAL, UNKNOWN. Diese Lektion zeigt dir, wie ein Plugin aufgebaut ist, wie die Zustände wechseln und warum dieses Modell auch noch nach 25 Jahren funktioniert.
1) Die vier Zustände – OK, WARNING, CRITICAL, UNKNOWN
Im Nagios-Modell hat jeder geprüfte Service genau einen von vier Zuständen. Diese Reduktion auf vier Stufen ist Stärke und Schwäche zugleich: einfach zu verstehen, aber gröber als Prometheus' kontinuierliche Metriken. Klick die Zustände an, um zu sehen, wie die Übergänge laufen:
2) Wie ein Check abläuft – Plugin live
Ein Plugin ist nichts anderes als ein Kommandozeilen-Programm, das von Nagios/Icinga in festen Intervallen aufgerufen wird (typisch alle 1–5 Min.). Es bekommt Parameter mitgegeben – etwa den Hostnamen und die Schwellenwerte – und liefert per Exit Code seinen Befund. Stell hier den aktuellen Wert und die Schwellen ein, um zu sehen, wie der Check reagiert:
OK | space=35% ist Nagios-Konvention: links menschlich lesbarer Text, rechts nach dem Pipe „Performance Data" für Graphen. Plugins finden sich gesammelt in Monitoring Plugins (vormals nagios-plugins) und NRPE-Plugins; Tausende weitere im Icinga Exchange.3) Architektur – Host, Service, Plugin
Nagios/Icinga arbeiten mit zwei Hauptobjekten: Host (z. B. srv-web01) und Service (z. B. disk-/-var, http-port-443). Pro Service ist genau ein Check-Command hinterlegt, das ein Plugin mit Parametern aufruft. Die Konfiguration besteht typisch aus diesen Bausteinen:
| Konzept | Bedeutung |
|---|---|
| Host | Ein zu überwachendes Gerät (Server, Switch, IP). Hat selbst einen Status (UP/DOWN/UNREACHABLE). |
| Service | Ein einzelner Check auf einem Host (z. B. „HTTPS-Antwortzeit"). Hat OK/WARNING/CRITICAL/UNKNOWN. |
| Hostgroup / Servicegroup | Gruppen für Massenkonfiguration („alle Webserver", „alle Datenbanken"). |
| Command | Definition eines Plugin-Aufrufs mit Platzhaltern. |
| Contact / Contactgroup | Wer wird wann benachrichtigt (E-Mail, SMS, Pager). |
| Timeperiod | Geschäftszeiten, Wartungsfenster, 24/7. |
| Notification | Die Regel, wie und wann ein Statuswechsel zur Aktion führt (siehe Alerting). |
4) Aktive vs. passive Checks
Es gibt zwei Wege, an Daten zu kommen: aktive Checks – Nagios ruft das Plugin selbst auf, in festen Intervallen, und entscheidet daraus den Zustand. Das ist Pull-Monitoring (siehe Monitoring-Konzept). Passive Checks – ein externes Programm liefert das Ergebnis ein, etwa über NSCA (Nagios Service Check Acceptor) oder einen REST-Endpoint. Das ist Push, und sinnvoll für: (a) Quellen hinter Firewalls, wo Nagios nicht reinkommt; (b) Events, die zeitlich unregelmäßig sind und schnell gemeldet werden müssen (Backup-Jobs am Ende); (c) verteilte Setups, in denen ein Master die Ergebnisse mehrerer Satelliten konsolidiert. Icinga 2 unterstützt das nativ mit dem Cluster-Modell.
5) Hard- vs. Soft-States – warum nicht jeder Fehler sofort Alarm ist
Ein zentrales Konzept, das in Prüfungen gerne gefragt wird: nicht jeder fehlgeschlagene Check löst sofort Alarm aus. Nagios unterscheidet Soft States (vorläufig) und Hard States (bestätigt). Wenn ein Service plötzlich von OK auf CRITICAL fällt, ist das erst ein Soft-CRITICAL. Erst nach mehreren aufeinander folgenden Bestätigungen (max_check_attempts, typisch 3) wird daraus ein Hard-CRITICAL, das Notifications auslöst. Ziel: einen kurzen Ausreißer (Netzwerk-Hickser, Aussetzer im DNS) nicht direkt eskalieren. Gleichzeitig sind beim Übergang Soft → Hard die Werte auf check_interval × max_check_attempts herabgesetzt – damit du innerhalb von ~3 Minuten Klarheit hast.
6) Nagios vs. Icinga vs. neuere Stacks
| Nagios Core | Icinga 2 | |
|---|---|---|
| Konfiguration | Klassische .cfg-Dateien | DSL (eigene Sprache), Objekt-orientiert, vererbbar |
| Web-UI | Basis-UI, Erweiterungen über Drittprodukte | Icinga Web 2, modern, eigenständig |
| Skalierung | Single-Master, Erweiterungen wie mod_gearman | Native Cluster & Zonen, mehrere Master |
| API | Eingeschränkt | Vollständige REST-API für Automatisierung |
| Plugin-Kompatibilität | Standard | 100 % kompatibel zu Nagios-Plugins |
Im FISI-Umfeld noch sehr verbreitet, gerade in mittelständischen Umgebungen. Bei größeren Cloud-Setups und Container-Welten lösen Prometheus & Grafana heute oft ab; Zabbix ist eine Alternative mit eingebautem Daten-Backend und größerer integrierter Funktionsfülle.
Zusammenfassung
Nagios (und sein moderner Fork Icinga) ist das schwellenwertbasierte Monitoring-Schwergewicht: vier Zustände – OK, WARNING, CRITICAL, UNKNOWN – pro Service, pro Host. Datenerhebung über Plugins – kleine Programme, die per Exit Code (0/1/2/3) ihren Befund melden, fast immer mit den Parametern -w (Warning-Schwelle) und -c (Critical-Schwelle). Aktive Checks pollen, passive Checks empfangen. Soft- vs. Hard-States verhindern Alarm bei kurzen Ausreißern. Konfigurations-Bausteine: Host, Service, Hostgroup, Command, Contact, Timeperiod. Icinga 2 hat moderne DSL-Konfiguration, REST-API und natives Clustering – Nagios-Plugins funktionieren weiter. Klassischer Vertreter für strukturierte IT-Infrastruktur-Überwachung.
Verwandte Lektionen: Monitoring-Konzept · Schwellenwerte & Alerting · Zabbix · und mehrWeitere relevante LektionenGrafana & PrometheusSNMPSyslogIncident ManagementService Level ManagementAnsible-PlaybooksServer-Dokumentation