0800 71 20000
Kontakt
...
Monitoring & Betrieb

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.

5 Kapitel mit allen Befehlen
Passende Kurse ansehen Persönlich beraten lassen
Betriebsingenieur beobachtet mehrere Monitoring-Bildschirme im Leitstand
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

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.

Miniatur-Szene: Leitstand mit drei Dashboard-Bildschirmen, Alarmglocke und rotierender Radarschüssel
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Migration in fünf Etappen

  1. 01 Bestandsaufnahme und Ausmisten
  2. 02 Zielsystem nach Plugin-Kompatibilität wählen
  3. 03 Parallelbetrieb ohne Alarmierung
  4. 04 Notifications gruppenweise umschalten
  5. 05 Nagios als Archiv abschalten
Was du mitnimmst

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.

Tutorial

Bestand exportieren, parallel betreiben, sauber abschalten

Die Migration läuft in fünf Etappen: Bestand aus der aufgelösten Konfiguration ziehen, Plugins auf Exit-Codes und Zustandsdateien prüfen, das Zielsystem parallel aufsetzen, die Konfiguration in dessen Denkmodell überführen und erst danach abschalten. Jeder Schritt endet mit einer Prüfung, die du auch nachts um drei noch nachvollziehen kannst.

01

Den Bestand exportieren, nicht abschreiben

Maßgeblich ist nicht, was in den Konfigurationsdateien steht, sondern was Nagios daraus auflöst. Templates, Vererbung und Hostgruppen erzeugen Services, die in keiner Datei wörtlich vorkommen.

Bestand und eigene Plugins ermitteln
# Konfiguration prüfen und die Objektzahlen ablesen
sudo nagios -v /etc/nagios/nagios.cfg | tail -20

# Welche Check-Kommandos werden tatsächlich referenziert?
grep -rhoP 'check_command\s+\K[^!\s]+' /etc/nagios/ | sort | uniq -c | sort -rn

# Eigene Plugins finden: alles, was zu keinem Paket gehört
rpm -qf /usr/lib64/nagios/plugins/* 2>&1 | grep 'not owned'   # RHEL-Familie
dpkg -S /usr/lib/nagios/plugins/* 2>&1 | grep 'no path found' # Debian/Ubuntu

Der Plugin-Pfad unterscheidet sich: /usr/lib64/nagios/plugins in der RHEL-Familie, /usr/lib/nagios/plugins unter Debian und Ubuntu. Wer den Pfad hart in Kommandodefinitionen stehen hat, bekommt beim Umzug auf eine andere Distribution flächendeckend UNKNOWN.

Was in die Inventarliste gehört

  • Hosts und Services mit ihren tatsächlichen Prüfintervallen, nicht mit den Template-Standardwerten
  • Kontakte, Kontaktgruppen, Zeitfenster und Eskalationen, denn daran hängt die Bereitschaft
  • Eigene Plugins samt Sprache, Abhängigkeiten und Autorin oder Autor
  • NRPE-Kommandos auf den überwachten Systemen, sie liegen dort und nicht auf dem Monitoring-Server
  • Alles, was per Ansible, Puppet oder Salt erzeugt wird, denn das muss zuerst umgestellt werden
02

Plugins prüfen: Exit-Code und Perfdata entscheiden

Ein Plugin, das sich an die Konvention hält, läuft in Icinga, Naemon und über MRPE auch in Checkmk unverändert weiter. Auffällig werden nur die Ausreißer, und die findest du in einer Stunde.

Ein Plugin so ausführen, wie das Monitoring es tut
# Unter dem Dienstbenutzer, nicht als root
sudo -u nagios /usr/lib/nagios/plugins/check_disk -w 10% -c 5% -p /var
echo $?    # 0 OK, 1 WARNING, 2 CRITICAL, 3 UNKNOWN

# Perfdata ist alles hinter dem senkrechten Strich
sudo -u nagios ./check_eigen.sh | awk -F'|' '{print "TEXT:", $1; print "PERF:", $2}'

# Laufzeit messen, das Zielsystem hat oft strengere Timeouts
time sudo -u nagios ./check_eigen.sh >/dev/null

Plugins, die einen Zähler zwischen zwei Läufen in einer temporären Datei ablegen, brechen beim Umzug. Das neue System läuft unter einem anderen Benutzer und findet die alte Statusdatei entweder nicht oder darf sie nicht schreiben. Solche Plugins gehören auf die Liste für den Umbau, nicht für den Umzug.

03

Parallelbetrieb aufsetzen

Kein Stichtag. Beide Systeme prüfen dieselben Hosts, genau eines benachrichtigt, das andere läuft still mit. So siehst du Abweichungen, bevor sie jemanden aufwecken.

Zweites System danebenstellen
# Naemon über OMD: eigene Site, eigener Port, gleiche Maschine möglich
sudo omd create migration
sudo omd config migration      # Core, Web-Oberfläche und Graphing wählen
sudo omd start migration

# Icinga 2: Konfiguration prüfen, bevor du neu lädst
sudo icinga2 daemon -C
sudo systemctl reload icinga2
sudo icinga2 object list --type Host --name web01

icinga2 daemon -C ist das Gegenstück zu nagios -v und gehört vor jedes reload. Ein restart wirft dagegen den Prüfzustand weg und du bekommst eine Welle von Erstmeldungen.

Der neue Server ist für die überwachten Systeme ein fremder Absender. In /etc/nagios/nrpe.cfg steht allowed_hosts, dort muss seine IP-Adresse ergänzt werden. Fehlt sie, antwortet jeder Check mit CHECK_NRPE: Error - Could not complete SSL handshake, und zwar erst nach dem Timeout, was den Parallelbetrieb zusätzlich verlangsamt. Plane außerdem ein, dass sich die Prüflast auf den Zielsystemen für die Dauer der Migration verdoppelt.

04

Die Konfiguration in das Zielmodell überführen

Naemon übernimmt deine Dateien fast unverändert. Icinga 2 und Checkmk verlangen ein anderes Denkmodell, dafür wird die Konfiguration kleiner statt größer.

Was das Zielsystem übernimmt und was du neu denken musst

ZielsystemNagios-KonfigurationNagios-PluginsNeues Denkmodell
Naemon mit OMDweitgehend unverändertja, unverändertkaum, es bleibt dateibasiert
Icinga 2nein, eigene Spracheja, als CheckCommandapply-Regeln statt Kopien je Host
Checkmknein, Regelwerkja, über MRPEder Agent liefert, der Server entscheidet per Service Discovery
Prometheusneinnein, Metriken statt ZuständeAlarme aus Zeitreihen per PromQL statt aus Exit-Codes
/etc/icinga2/conf.d/services.conf
// Eine Regel statt einer Servicedefinition je Host
apply Service "disk-var" {
  check_command = "disk"
  vars.disk_partitions = "/var"
  check_interval = 5m
  retry_interval = 1m
  assign where host.vars.rolle == "linux"
  ignore where host.vars.wartung == true
}

Aus dreihundert kopierten Servicedefinitionen wird eine apply-Regel plus ein Attribut am Host. Genau darin liegt der Gewinn der Umstellung, und genau deshalb lohnt es nicht, die alte Struktur eins zu eins nachzubauen.

/etc/check_mk/mrpe.cfg auf dem überwachten System
# Servicename und Kommandozeile, getrennt durch Leerzeichen
Lizenzpruefung /usr/local/lib/nagios/plugins/check_lizenz.sh -w 30 -c 14
Backupalter    /usr/local/lib/nagios/plugins/check_backup_age.sh -c 26

MRPE führt klassische Plugins über den Checkmk-Agenten aus und übernimmt Exit-Code und Perfdata. Damit kannst du eigene Prüfungen mitnehmen, ohne sie sofort neu zu schreiben. Der Servicename darf kein Leerzeichen enthalten.

05

Benachrichtigungen, Historie und Abschaltung

Der Umschaltpunkt ist nicht der Tag, an dem das neue System läuft, sondern der Tag, an dem es benachrichtigt. Erst danach darf das alte System stiller werden.

Bevor das alte System die Benachrichtigung abgibt

  • Jeden Host und Service des Altsystems im neuen wiedergefunden und die Differenz erklärtFehlen werden zuerst die Checks, die selten Alarm schlagen. Genau die vermisst monatelang niemand, und genau sie hätten den nächsten Ausfall gemeldet.
  • Einen echten Alarm über jeden Benachrichtigungsweg ausgelöstSMTP-Relay, Absenderadresse und SMS-Gateway kennen den neuen Server nicht. Ein Relay, das die neue IP nicht in seiner Zulassungsliste hat, verwirft die Mail lautlos.
  • Eskalationen und Bereitschaftszeitfenster nachgebaut und einmal über Nacht getestetZeitfenster sind der Teil, den die Migration am häufigsten verliert. Das fällt erst am ersten Wochenende auf, an dem niemand geweckt wird.
  • Downtime und Acknowledge im neuen System mit dem Team geübtOhne geübten Wartungsmodus quittiert im ersten Wartungsfenster niemand die Meldungen, und das halbe Team bekommt Alarme für einen geplanten Reboot.
  • Konfigurationsverwaltung auf das neue System umgestelltSolange Ansible oder Puppet noch die alten Objektdateien ausrollen, überschreibt der nächste Lauf deine Migrationsstände und niemand versteht, warum die Änderung verschwunden ist.
  • Altsystem als Nur-Lese-Instanz stehen lassen, Benachrichtigungen ausReports und Verfügbarkeitsnachweise der vergangenen Jahre liegen dort. Ein Jahr Weiterlaufen ist billiger als jede Datenübernahme.
Passende Kurse

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.

Monitoring mit Naemon / Nagios / OMD 5 Tage Präsenz nächster Termin 12.10.2026 Zum Kurs Nagios Training: OpenSource Netzwerk und Systems Monitoring 3 Tage Präsenz nächster Termin 19.10.2026 Zum Kurs Zabbix Administration Komplettkurs 3 Tage Präsenz nächster Termin 05.10.2026 Zum Kurs Monitoring mit Prometheus und Grafana - Grundkurs 3 Tage Präsenz oder Live-Online nächster Termin 09.11.2026 Zum Kurs Nagios Training: Visualisierung mit PNP4Nagios und NagVis 2 Tage Präsenz nächster Termin 17.09.2026 Zum Kurs
Unverbindlich beraten lassen Alle DevOps-Kurse ansehen
Gut zu wissen

Häufige Fragen zu Nagios-Ablösung

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Kann ich meine bestehenden Nagios-Plugins weiterverwenden?
In den allermeisten Fällen ja. Naemon, Icinga 2 und Checkmk führen Plugins aus, die sich an die klassische Konvention halten, also eine Ausgabezeile mit optionalen Performance-Daten liefern und mit 0 für OK, 1 für WARNING, 2 für CRITICAL und 3 für UNKNOWN beenden. Bei Checkmk bindest du sie über MRPE oder als lokale Checks des Agenten ein, bei Zabbix brauchst du dagegen einen Wrapper, weil dort das Item- und Trigger-Modell eine andere Trennung zwischen Messwert und Bewertung vorsieht.
Was ist der Unterschied zwischen Naemon, Icinga und Checkmk in der Praxis?
Naemon ist der direkte Nagios-Nachfolger und der Weg mit den wenigsten Änderungen, weil Konfigurationssyntax und Plugins bleiben, wie sie sind. Icinga 2 verlangt eine neue Konfiguration, gibt dir dafür Regeln statt Copy-and-Paste, eine verteilte Architektur mit Satelliten und eine REST-API für Automatisierung. Checkmk verschiebt den Schwerpunkt vom aktiven Check zur Agenten-Erhebung mit automatischer Service-Erkennung, was bei vielen gleichartigen Servern spürbar weniger Pflege bedeutet, bei sehr individuellen Checks aber Umdenken erfordert.
Ersetzt Prometheus Nagios?
Nur teilweise, und das sollte man ehrlich sagen. Prometheus ist stark bei metrikbasierter Überwachung von Anwendungen und dynamischen Umgebungen, weil es Ziele über Service-Discovery findet und Alarme über Regeln auf Zeitreihen bildet. Für aktive Erreichbarkeitsprüfungen gegen Netzwerkgeräte, Appliances oder alte Applikationen, für die es keinen Exporter gibt, bleibt das klassische Check-Modell praktikabler. Der Blackbox Exporter deckt einen Teil davon ab, ersetzt aber keine hundert gewachsenen Spezialchecks.
Wie lange dauert eine Nagios-Migration realistisch?
Das hängt weniger an der Zahl der Hosts als an der Zahl der Sonderfälle. Eine überschaubare Umgebung mit standardisierten Checks lässt sich in wenigen Wochen umstellen, eine gewachsene Installation mit Eigenentwicklungen, Eskalationslogik und Schnittstellen zu Ticketsystemen braucht eher mehrere Monate im Parallelbetrieb. Plan die Zeit für die Aufräumphase am Anfang fest ein, sie zahlt sich später doppelt zurück.
Muss ich alles auf einmal umstellen?
Nein, und das ist bei größeren Umgebungen auch nicht empfehlenswert. Migriere entlang von Servicegruppen oder Standorten, lass beide Systeme parallel prüfen und schalte die Benachrichtigungen erst gruppenweise um, wenn die Ergebnisse im Vergleich übereinstimmen. Ein Rückweg bleibt so bis zuletzt offen, weil die alte Konfiguration noch vollständig vorhanden ist.

Zuletzt geprüft am 26. Juli 2026.

Weiterlesen

Verwandte Linux-Themen

Alle Linux-Themen im Überblick
Monitoring & Betrieb Linux-Server langsam? So findest du die Ursache systematisch Ansehen Monitoring & Betrieb Monitoring Tools im Vergleich: Welches Open-Source-Werkzeug passt zu deiner Infrastruktur? Ansehen Monitoring & Betrieb Zentrales Logging unter Linux: Logs sammeln, auswerten und im Ernstfall nachweisen Ansehen Strategie & Migration Open Source in Behörden einführen: dein operativer Fahrplan Ansehen
Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

“
Der Trainer konnte die Inhalte sehr gut vermitteln. Ich habe dabei viel gelernt.
Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“
“
Trainer gut und verständlich. Unterlagen nur zum lesen (keine Kopierfunktion). Wissenstransfer erfolgreich.
Rückmeldung aus dem Kurs „SUSE Linux Enterprise 15 High Availability Deployment – HAE311v15“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail
Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

0800 71 20000 E-Mail
Nächster Schritt

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.

Beratung anfragen 0800 71 20000