Nagios ablösen, ohne deine Checks wegzuwerfen
Deine Checks musst du nicht wegwerfen: Icinga 2 und Naemon übernehmen sie weitgehend direkt, Checkmk und Prometheus verlangen dagegen ein neues Denkmodell. Entscheide danach, ob du Kontinuität willst oder einen Schnitt.
Warum der Ausstieg aus Nagios so lange liegen bleibt
Die typische Ausgangslage sieht überall ähnlich aus: ein Nagios-Core, dutzende include-Dateien mit host- und service-Definitionen, ein Wildwuchs aus Templates und hostgroups, dazu NRPE auf den Servern, check_by_ssh für die Sonderfälle und ein Satz eigener Plugins in Perl, Bash und Python, den seit Jahren niemand mehr angefasst hat. Genau dieser Satz ist der eigentliche Wert deines Monitorings, weil dort das Wissen über eure Anwendungen steckt. Wer das Monitoring wechselt, hat Angst, dieses Wissen neu schreiben zu müssen.
Dazu kommen zwei weitere Bremsen. Erstens die Historie: RRD-Dateien aus PNP4Nagios und Weathermaps oder NagVis-Karten sind an das alte System gebunden, und niemand will die Verfügbarkeitsauswertungen der letzten Jahre verlieren. Zweitens der Betrieb selbst, denn ein Monitoring darf während der Umstellung keine Lücke haben. Ein Big-Bang-Wechsel an einem Wochenende ist bei mehreren tausend Services schlicht nicht realistisch.
Der häufigste Fehler ist deshalb nicht die falsche Toolwahl, sondern die falsche Reihenfolge. Teams entscheiden sich für ein neues System, migrieren die Konfiguration eins zu eins mit einem Konverter und übernehmen dabei jeden Altlast-Check, jede tote Host-Definition und jede Notification-Eskalation, die schon in Nagios niemand mehr verstanden hat. Der zweite verbreitete Fehler ist die Annahme, Prometheus sei ein direkter Nagios-Ersatz. Für dynamische Container-Workloads ist es das richtige Werkzeug, für aktive Checks gegen Switches, USVs, Drucker oder alte Appliances per SNMP und SSH ist es das nicht.
Migration in fünf Etappen
- 01 Bestandsaufnahme und Ausmisten
- 02 Zielsystem nach Plugin-Kompatibilität wählen
- 03 Parallelbetrieb ohne Alarmierung
- 04 Notifications gruppenweise umschalten
- 05 Nagios als Archiv abschalten
Der Weg aus Nagios heraus, Schritt für Schritt
Die gute Nachricht vorweg: Die Nagios-Plugin-Schnittstelle ist ein sehr schlichter Vertrag. Ein Plugin schreibt eine Statuszeile nach stdout, hängt hinter einem senkrechten Strich optional Performance-Daten an und liefert einen Exit-Code zwischen 0 und 3. Alle ernstzunehmenden Nachfolger sprechen diesen Vertrag weiterhin, und darauf lässt sich eine Migration in Etappen aufbauen.
Bestand aufnehmen, bevor du Werkzeuge vergleichst
Zieh dir aus der laufenden Instanz die tatsächlich ausgeführten Checks, nicht die Konfigurationsdateien. Welche Services haben in den letzten zwölf Monaten überhaupt einen Zustandswechsel gehabt, welche Notifications sind wirklich bei Menschen gelandet und welche Plugins liegen zwar in libexec, werden aber nirgends referenziert. Erfahrungsgemäß fällt hier ein erheblicher Teil der Konfiguration ersatzlos weg, und jeder Check, den du nicht migrierst, kostet auch keine Migrationszeit.
Den passenden Nachfolger nach Kompatibilitätsgrad wählen
Naemon ist ein Fork des Nagios-Cores und bleibt der konservativste Weg, weil deine bestehende Konfigurationssyntax und deine Plugins weiterlaufen und du über OMD gleich Thruk, Livestatus und die Graphen mitbekommst. Icinga 2 bringt eine eigene Konfigurationssprache mit Regeln, Apply-Direktiven und einer verteilten Master-Satellite-Architektur, führt aber ebenfalls klassische Plugins aus. Checkmk arbeitet primär agentenbasiert mit automatischer Service-Erkennung und bindet deine Altplugins über MRPE oder lokale Checks ein. Zabbix wiederum ist der größte Bruch, weil Templates, Items und Trigger ein anderes Datenmodell sind, dafür bekommst du Autodiscovery und ein durchgängiges Web-Frontend.
Parallelbetrieb statt Stichtag
Setz das neue System neben Nagios auf und lass beide eine Zeit lang gleichzeitig prüfen. In der ersten Phase verschickt nur die alte Instanz Benachrichtigungen, das neue System sammelt still mit. So siehst du Abweichungen bei Schwellwerten, Timeouts und Check-Intervallen, bevor sie um drei Uhr nachts jemanden aus dem Bett holen. Erst wenn eine Servicegruppe im Vergleich sauber läuft, wandern die Notifications für diese Gruppe um und die Checks verschwinden aus der Nagios-Konfiguration.
Plugins konsolidieren, nicht nur umziehen
Nutz die Migration, um die eigenen Plugins auf einen gemeinsamen Stand zu bringen: einheitliche Argumente für Warning- und Critical-Schwellen, saubere Performance-Daten mit Einheiten und Grenzwerten, definierte Timeouts und ein Exit-Code 3 statt eines Stacktrace, wenn etwas unerwartet ist. Wo NRPE nur noch aus historischen Gründen läuft, prüf den Wechsel auf einen Agenten des neuen Systems oder auf passive Checks, die die Hosts selbst einliefern.
Historie und Visualisierung bewusst entscheiden
Kläre früh, ob du die alten RRD-Daten wirklich brauchst. Oft reicht es, die Nagios-Instanz nach der Migration im Read-Only-Modus als Archiv weiterlaufen zu lassen oder Reports für den Abschlusszeitraum zu exportieren, statt eine Datenkonvertierung zu bauen. Für die Zukunft lohnt es sich, Metriken in eine Zeitreihendatenbank zu schreiben und die Dashboards in Grafana zu bauen, damit die Auswertung nicht wieder am Monitoring-Tool klebt.
Prometheus dort ergänzen, wo es hingehört
Für Kubernetes, für Anwendungen, die selbst Metriken exponieren, und für alles, was dynamisch kommt und geht, ist das Pull-Modell mit Service-Discovery deutlich besser geeignet als statische Host-Definitionen. Für Infrastruktur, die man aktiv von außen anfassen muss, bleibt das klassische Check-Modell. Viele Betriebe fahren deshalb dauerhaft zweigleisig und führen nur das Alerting zusammen, etwa über Alertmanager und eine gemeinsame On-Call-Kette.
Kurse zu Nagios-Ablösung bei cmt
Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.
Häufige Fragen zu Nagios-Ablösung
Noch etwas offen? Wir sind ohne Warteschleife für dich da.
Frag uns direktKann ich meine bestehenden Nagios-Plugins weiterverwenden?
Was ist der Unterschied zwischen Naemon, Icinga und Checkmk in der Praxis?
Ersetzt Prometheus Nagios?
Wie lange dauert eine Nagios-Migration realistisch?
Muss ich alles auf einmal umstellen?
Zuletzt geprüft am 26. Juli 2026.
Verwandte Linux-Themen
Alle Linux-Themen im ÜberblickEchte Stimmen aus unseren IT-Kursen
Der Trainer konnte die Inhalte sehr gut vermitteln. Ich habe dabei viel gelernt.
Trainer gut und verständlich. Unterlagen nur zum lesen (keine Kopierfunktion). Wissenstransfer erfolgreich.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.
Migration mit unseren Monitoring-Trainern durchsprechen
Wenn du deine Nagios-Umgebung ablösen willst, kannst du das Handwerkszeug bei cmt direkt lernen. Im Kurs Monitoring mit Naemon, Nagios und OMD arbeitest du an der Migrationsstrecke inklusive OMD, Livestatus und Thruk, der Zabbix Administration Komplettkurs zeigt dir den Wechsel auf ein anderes Datenmodell, und Monitoring mit Prometheus und Grafana klärt, was du sinnvoll ergänzen statt ersetzen solltest. Alle Termine gibt es als Präsenz- und als Live-Online-Schulung, und für eine Einschätzung zu deiner konkreten Umgebung meldest du dich einfach bei uns.