Es gibt viele Gründe, die für einen Wechsel von Nagios zu einem anderen Monitoring-Tool sprechen. Die IT-Consultants von tribe29 haben bereits einige Unternehmen bei der Ablösung von Nagios begleitet und ich möchte Ihnen in diesem Blogpost zeigen, wie Sie mit relativ wenig Aufwand Ihr Monitoring von Nagios auf Checkmk migrieren können.

Checkmk eignet sich optimal als Nagios-Alternative, da es als ehemaliger Nagios-Fork viele bekannte und bewährte Konzepte von Nagios unterstützt. Checkmk adressiert aber die meisten Schwachstellen von Nagios mit neuen Konzepten und erleichtert dadurch das Monitoring erheblich.

In diesem Beitrag werden wir eine kleine Nagios-Umgebung zu Checkmk migrieren. Meine Anleitung setzt auf einige Features und Möglichkeiten von Checkmk, die Nagios so nicht beherrscht. Theoretisch können Sie mit Checkmk auch weite Teile von Nagios direkt übernehmen, allerdings bedeutet dies in der Regel mehr Aufwand. Sie müssen keinerlei Erfahrung mit Checkmk mitbringen. Es ist keine Konfiguration einer Datenbank oder von Plugins nötig. Checkmk hat alles an Bord, was Sie für den Wechsel brauchen.

In meiner Anleitung arbeite ich weitgehend ohne die Kommandozeile, allerdings können Sie Checkmk auch über APIs konfigurieren. Genauso kann Checkmk Nagios-Plugins übernehmen, beides ist aber nur in Ausnahmefällen sinnvoll. Die Checkmk-Benutzeroberfläche erleichtert die Nutzung und die offiziellen Checkmk-Plug-Ins arbeiten effizienter und zuverlässiger.

Es gibt natürlich auch andere Möglichkeiten, um seine Nagios-Umgebung abzulösen. So könnte die Nagios-Konfiguration und alle Hosts durch Livestatus ausgelesen werden und durch Nutzung der Checkmk-APIs direkt in Checkmk übertragen werden (Livestatus ist übrigens auch eine Entwicklung vom Checkmk-Team). Dadurch wäre eine Migration selbst von großen Umgebungen ohne Downtime möglich.

Dies bedarf aber guter Linux-Kenntnisse und ist ebenfalls mit Aufwand verbunden. Die optimale Lösung hängt sicherlich von der Konfiguration und dem Umfang der eigenen Nagios-Instanz ab. Diese Anleitung sollte sich gut für die meisten Einsatzszenarien eignen. Gerne freue ich mich über Feedback als Kommentar unter dem Blogpost. Außerdem können Sie Ihre Ideen oder Probleme jederzeit im Checkmk-Forum teilen.

Bevor es losgeht: Das Setup meiner Nagios-Instanz

Ich liste in diesem Kapital die Details meiner Nagios-Instanz auf. In meinem Setup betreibe ich Nagios Core Version 4.4.5 und ich ziehe das Monitoring in die Checkmk Raw Edition 2.0.0.7b um. Sie können mit dieser Anleitung auch ohne Probleme von einer kommerziellen Nagios-Umgebung zu Checkmk wechseln. Außerdem können Sie auch direkt die Checkmk Enterprise Edition als Nagios-Alternative nutzen oder später ihr Monitoring ganz einfach von der Raw Edition auf die Enterprise Edition von Checkmk umziehen. Ich greife hier bei Nagios sowie bei Checkmk auf die Open-Source-Versionen zurück. In jedem Fall sollten Sie eine aktuelle Version von Checkmk nutzen, eine solche findet sich im Download-Bereich.

Meine Nagios-Instanz läuft auf einem CentOS-Server 7 (Version 7.9.2009). Neben Nagios habe ich die Nagios-Standard-Plugins und den Nagios Remote Plugin Executer (NRPE) installiert. Insgesamt habe ich vier Hosts mit insgesamt 24 Services im Monitoring: Meinen Nagios-Host-Server (localhost), einen weiteren Linux-Server, einen Windows-Server und einen Cisco-Switch (sw-01.lan.tribe29.com). Für alle Hosts und Services habe ich entsprechende Definitionen erstellt. Wie der Screenshot aus Nagios zeigt, sind alle online und für meinen Nagios-Host erreichbar.

Für den Linux-Host und den Windows-Host habe ich einige Standard-Nagios-Services konfiguriert. Auf meinem Linux-Server habe ich NRPE v4.0.3. installiert, um Daten an meine Nagios-Instanz zu senden. Auf dem Windows-System habe ich den NSClient++ Monitoring-Agent als Windows-Service installiert, um die Daten zu Nagios zu übertragen. Den Switch überwache ich über das Standard-SNMP-Plugin von Nagios. Jeden Host habe ich auf dem Nagios-Server manuell über die Kommandozeile konfiguriert.

Nagios-Übersicht der Hosts samt Status

Für mein Nagios-Monitoring habe ich drei Kontaktgruppen mit je zwei Nutzern definiert. Die Anzahl der Hosts, Services, Nutzer und Kontaktgruppen sind in meiner Nagios-Umgebung relativ klein, es lassen sich jedoch auch wesentlich umfangreichere Umgebungen problemlos migrieren.

Die Hosts in der Nagios-Config

Vorbereitung: Checkmk aufsetzen

Wir installieren erstmal Checkmk auf einem zusätzlichen Server – vom Betrieb von Nagios und Checkmk auf demselben Server ist aus Stabilitätsgründen in jedem Fall abzuraten.

Checkmk arbeitet zwar wesentlich effizienter als Nagios, dennoch sollte man für den Monitoring-Server ausreichend Hardware-Ressourcen bereitstellen. Ein Vorteil von Checkmk ist, dass Sie Services nicht mehr manuell konfigurieren müssen. Durch die automatische Service-Discovery werden Sie am Ende mehr wichtige Services pro Host bei gleichzeitig weniger Aufwand im Monitoring haben. In meinem Fall habe ich zwar genauso viel Hosts wie zuvor, die Zahl der Services hat sich aber vervierfacht.

Ich habe für diese Anleitung, wie im Handbuch beschrieben, Checkmk Raw 2.0.0b7 auf einem Linux-Server (Ubuntu 20.04) aufgesetzt. Das „b“ in 2.0.0b7 steht für Beta. Für die Migration sollten Sie natürlich immer eine aktuelle, stabile Version verwenden.

Für die Nagios-Migration setzen Sie zunächst eine Instanz mit der Checkmk-Edition Ihrer Wahl auf und starten diese. Da Checkmk als integriertes Paket ausgeliefert mit, ist die Installation im Handumdrehen erledigt und benötigt keine separate Installation einer Datenbank oder eines Webservers. Nach der Anmeldung über die grafische Oberfläche sehen Sie nun ein leeres Monitoring.

SNMP-Geräte in Checkmk aufnehmen

Das ändern wir jetzt, indem Sie ein Gerät in Checkmk aufnehmen, dass Sie nicht mit Agenten überwachen können. Das betrifft in der Regel Netzwerkgeräte, die man nur mit SNMP überwachen kann. Bei SNMP scheiden sich die Geister, für mich ist „SNMP a Necessary Evil“. Zum Glück abstrahiert Checkmk die Komplexität von SMNP und bietet von Haus aus Plug-Ins für nahezu jedes Netzwerkgerät und ich muss als Nutzer nicht mit den Eigenheiten von SNMP herumschlagen.

Wenn Sie viel Netzwerk-Monitoring vorhaben, empfehle ich unseren Blogartikel „Netzwerk-Monitoring: Four Rules to rule them all“ vor einer Migration zu lesen und der Anleitung dort zu folgen. In meinem Fall habe ich nur einen Switch und nutze die Standardeinstellungen von Checkmk.

Zum Hinzufügen Ihres Hosts gehen Sie auf Setup ➳ Hosts. Oben links finden Sie dann den Knopf Add host. Klicken Sie darauf und füllen anschließend die nötigen Felder für diesen Host aus.

Hinzufügen von Hosts in Checkmk

Ich möchte wie in meiner alten Nagios-Umgebung einen Alias-Namen vergeben. Unter BASIC SETTINGS sind das „Hostname“ und „Alias”. Wenn der Name des Hosts richtig geschrieben ist, kann Checkmk ihn auflösen und die IP-Adresse selbstständig identifizieren. Zur Demonstration trage ich aber die IP-Adresse ebenfalls ein. Bei DATA SOUCES stellen Sie "Checkmk Agent" auf „No agent“ und stellen im Feld „SNMP“ darunter auf die gewünschte SNMP-Version, hier „SNMP v2 or v3“.

Im nächsten Feld müssen Sie die "SNMP credentials" eintragen – oder auch nicht: Ich nutze wie die meisten Unternehmen SNMP v2c und habe die Standard Community für meinen Switch nicht verändert. Daher kann ich den Default value behalten. Als Default nutzt Checkmk hier für die SNMP-Community „public“. Weichen Sie hier von den Standard-SNMP-Zugangsdaten ab, sollten Sie das entsprechend anpassen. Für meinen Switch sieht das so aus:

Checkmk startet mit einer automatischen Service-Erkennung

Nach der Eingabe klicken Sie oben rechts auf Save & go to service configuration. Checkmk versucht nun die Monitoring-Daten vom Switch abzufragen. Wenn dies erfolgreich ist, sollte Checkmk Ihnen jetzt unter anderem eine Liste mit Ports anzeigen und Sie fragen, ob Sie diese als Services in das Monitoring aufnehmen möchten. 

Genau wie bei mir werden Ihnen jetzt einige Ports fehlen, denn Checkmk ist aktuell so eingestellt, dass es nur Ports erkennt, die gerade online sind. Das ist der Preis für die Abkürzung. Die bessere Lösung stellt mein Kollege im erwähnten SNMP-Blogpost vor. An dieser Stelle hat er mit Hilfe von Regeln und Tags das SNMP-Monitoring in Checkmk verfeinert, sodass es unter anderem auch Ports mit in das Monitoring aufnimmt, die gerade offline sind. Für meinen Beispiel-Switch gebe ich mich hier mit den Ports zufrieden, die gerade online sind.

Wenn Sie keine Einzelauswahl treffen, wählt Checkmk automatisch alle erkannten Ports aus und übernimmt diese in das Monitoring. Außerdem hat mein Checkmk durch die Nutzung des Check-Plugins snmp_info erkannt, dass es sich bei dem Host um einen Switch handelt und deshalb automatisch ein passendes Host-Label vergeben. Klicken Sie auf Fix all, um alle Services in das Monitoring zu zu übernehmen. Checkmk zeigt nun die Ports als Services und das Monitoring meines Switches ist fast abgeschlossen.

Checkmk übernimmt Services und Labels automatisch

Allerdings muss ich die Änderungen noch annehmen. Gehen Sie dazu oben rechts auf changes, um in die Übersicht der Pending Changes zu gelangen. Setzen Sie unter Activation status vorne bei der betreffenden Checkmk-Instanz den Haken und klicken Sie auf Activate on selected sites. Damit haben Sie den ersten Host in Ihrem neuen Monitoring aufgenommen.

Ordner für Hosts in Checkmk erstellen

Das war im Vergleich zu Nagios zwar vergleichsweise einfach, aber natürlich möchten Sie jetzt nicht jeden Host einzeln in das Monitoring aufnehmen. Das Arbeiten mit Ordnern in Checkmk ist ein guter Anfang, um sich den Monitoring-Alltag leichter zu machen.

Unter Setup ➳ Hosts können Sie solche Ordner für Ihre Hosts erstellen. Die Ordner gab es so in meinem Nagios nicht. Da die Verwaltung über Ordner in Checkmk aber ein mächtiges Werkzeug ist, wollen wir es gleich zu Anfang ausprobieren.

Klicken Sie auf Add subfolder und benennen Sie den Ordner nach Ihren Wünschen. Ich habe für meine Hosts die drei Ordner „Linux servers“, „Windows servers“ und „Network devices“ erstellt. Alle Hosts bekommen die Einstellungen des Ordners automatisch vererbt. Sie können also beispielsweise die Anpassung für SNMP einmal im passenden Ordner festlegen und müssen in Zukunft bei der Host-Erstellung den Host nur dem Ordner zuweisen.

So habe ich in meinem Ordner „Network devices“ als DATA SOURCES für diesen Ordner genau wie bei meinem Cisco-Switch oben „No agent“ und „SNMP v2 or v3“ gesetzt. In Zukunft kann ich dann meine Netzwerkgeräte bei der Host-Erstellung in diesen Ordner schieben und muss keine weiteren Konfigurationen mehr vornehmen. Außerdem können Sie im Main directory bestehende Hosts über das Ordner-Symbol mit dem Pfeil den gewünschten Ordnern zuweisen. Vergessen Sie nicht, die Änderungen anzunehmen. Ich habe meinen Cisco-Switch direkt in den Ordner geschoben.

Ordner sind ein mächtiges Werkzeug in Checkmk

Sie können sich mit den Ordnern einfach Templates bauen, um später eine große Menge an Hosts mit nur ein paar Klicks in das Monitoring zu übernehmen. Checkmk unterstützt zudem auch Bulk Imports von Hosts über CSV-Listen oder automatisierte Skripte über die Kommandozeile. Es ist aber sinnvoll, erste Hosts über die GUI in das Monitoring aufzunehmen, um Erfahrungen mit Checkmk zu sammeln.

Neben den Ordnern bietet Checkmk mit Labels und Tags gute Möglichkeiten, um auch große Monitoring-Umgebungen mit sehr vielen Hosts leicht zu verwalten.

Checkmk-Agenten auf zu überwachenden Systemen installieren

Im nächsten Schritt sollten Sie Ihre Hosts mit den entsprechenden Checkmk-Agenten versorgen. Dazu brauchen Sie einen Root-Zugang zu den Systemen. Die Agenten in der Raw Editon befinden sich unter Setup ➳Agents.

Checkmk liefert alle Agenten mit

In meinem Monitoring habe ich drei Server, die ich über Agenten überwachen möchte. Je einen produktiven Linux- und Windows-Server und dann noch mein Monitoring-Host-System. Für die Linux-Systeme logge ich mich als Admin ein und installiere das entsprechende Agenten-Paket. Auf dem Windows-Server führe ich die MSI-Datei lokal aus und installiere den Checkmk-Agenten als Windows-Dienst. Damit habe ich in meinem Beispiel dafür gesorgt, dass die Checkmk-Agenten die Überwachungsdaten zu Checkmk übertragen.

Im Handbuch finden Sie eine genaue Anleitung, wie Sie die jeweiligen Agenten auf Ihren Server-Plattformen installieren. Außerdem stehen Agenten-Plugins für viele weitere Systeme bereit, um diese tiefgreifend überwachen zu können. Da Checkmk-Erweiterungen in der Regel mehr Informationen bei weniger Ressourcenverbrauch liefern, lohnt es sich alte Nagios Plug-Ins durch entsprechende Checkmk Plug-Ins zu ersetzen.

Beachten Sie zudem, dass sich die Checkmk-Plugins auch durch lokale Checks erweitern lassen. Sie können auch Nagios-Plugins in lokale Checks für Checkmk umwandeln. Falls es für ein System kein offizielles Plugin gibt, können Sie bestehende Erweiterungen anderer Monitoring-Tools an die Richtlinien von Checkmk anpassen. Viele unserer Kunden setzen dies erfolgreich in der Praxis um. Beachten Sie aber, dass tribe29 in diesem Fall keinen Support garantieren kann.

Systeme als Hosts in das Monitoring aufnehmen

Wenn die Agenten auf den Systemen laufen, können wir die Systeme jetzt in das Monitoring aufnehmen. Für mein kleines Nagios-System und zur Vorstellung des Prinzips machen wir das wieder über die GUI.

Wir fangen mit unserem Monitoring-Server localhost an. Gehen Sie wieder unter Setup ➳ Hosts, öffnen Sie den entsprechenden Ordner und legen Sie ihn mit Add Host an. Geben Sie „localhost“ als Hostname an. Dies reicht bereits, Sie können die anderen Felder frei lassen. Checkmk geht ohne Anpassung der Host-Einstellungen Ihrerseits immer davon aus, dass Sie einen Host über den Agenten überwachen möchten. Ich muss also nur den Host-Namen korrekt eingeben und eine vernünftige Namensauflösung in meinem Netzwerk haben.

Hinzufügen des localhosts

Klicken Sie wieder auf Save & go to service configuration, um die automatische Service-Erkennung zu starten. Die weiteren Schritte verlaufen identisch wie beim Monitoring des Switches.

Nicht vergessen, die Änderungen anschließend wieder anzunehmen. Genau nach diesem Schema habe ich meinen localhost, meinen Windows- und meinen anderen Linux-Server hinzugefügt.

Host-Gruppen, Benutzer und andere Alarme konfigurieren

Checkmk bietet natürlich auch die Möglichkeit, Hosts und Benutzer in Gruppen zu verwalten. Außerdem gibt es zahlreiche Alarmierungsmechanismen. Wie bereits beim Thema Labels, Tags und Ordner erwähnt, gehen diese oftmals über die Möglichkeiten von Nagios hinaus und lassen sich je nach Wunsch kombinieren.

Viel wichtiger ist aber, dass Sie dies nicht mehr über die Kommandozeile tun müssen, sondern bequem über die Benutzeroberfläche. Vergessen Sie also die Arbeit mit Nagios-Objekten, die Sie über Config-Files mühsam definieren mussten. Stattdessen finden Sie im Checkmk-Handbuch genaue Anleitungen und können dort einfach nach den gewünschten Punkten wie Benutzerverwaltung, Alarme Verwaltung der Hosts suchen.

Ich habe an dieser Stelle wieder meine sechs Benutzer in drei Kontaktgruppen samt Kontaktdaten erstellt. Die Host-Gruppen habe ich ebenfalls schnell nachgebaut. Es hängt von Ihnen ab, wie Sie Ihr Checkmk aufbauen möchten, aber mit Hilfe des Handbuchs ist es relativ einfach, Checkmk nach Belieben anzupassen. Wenn Sie Ihr Monitoring nach Ihren Wünschen konfiguriert haben, können die Migration abschließen.

Abschluss der Migration

Sie sind an dieser Stelle fast fertig. Sie überwachen jetzt aber einige Systeme doppelt. Gerade bei meinem Switch greifen jetzt Nagios und Checkmk auf den SNMP-Agenten zu. Ich habe daher meine Nagios-Instanz abgeschaltet und empfehle Ihnen das Gleiche zu tun. Außerdem können Sie die alten Nagios-Agenten von Ihren Hosts löschen.

Wie erwartet hat Checkmk mehr Services gefunden. Unter Nagios waren 24 Services, jetzt sind es 107. Ganz ohne manuelle Konfiguration. Auf meinem Windows-Host zeigt mir Checkmk direkt ein paar kritische Werte an, die ich vorher im Nagios nicht gesehen habe.

Übersicht über die Hosts nach der Migration

Wie bereits erwähnt, ist dies wirklich nur eine von mehreren Möglichkeiten für die Migration weg von Nagios. Für sehr große Umgebungen kann es sich lohnen, Hosts über ein Skript auf einen Schlag über die Kommandozeile zu migrieren. Die Checkmk-Schnittstelle Livestatus kann dazu aus Daten zu sämtlichen Nagios-Objekten aus Ihrer Nagios-Umgebung auslesen. Allerdings ist es relativ leicht mit Checkmk Hosts zu erstellen, so dass man mit dem hier beschriebenen Ansatz in der Regel sicherer und einfacher fährt.

Ihre spannende Reise mit Checkmk beginnt jetzt erst. Als Nagios-User finden Sie sich sicherlich leicht zurecht und ich bin mir sicher, dass Sie Nagios nicht vermissen werden. Neben dem Handbuch können Sie ein Checkmk-Training besuchen oder fragen Sie im Forum, wenn Sie tiefer einsteigen möchten oder noch Fragen haben.

Happy Monitoring!


Related Articles

Luftqualitäts-Monitoring mit Checkmk
Luftqualitäts-Monitoring mit Checkmk
Luftqualitätsüberwachung mit Checkmk: Auf der Checkmk Conference #9 haben wir mit CO2-Ampeln die Luftqualität gemonitort und entsprechende Dashboards…
Dashboard für vSphere-Monitoring in Checkmk erstellen
Dashboard für vSphere-Monitoring in Checkmk erstellen
Checkmk bietet eine große Auswahl an vordefinierten Dashboards, unterstützt aber auch das Erstellen individueller Dashboards. In diesem Tutorial…
So werden Sie Ihre eigene Certificate Authority
So werden Sie Ihre eigene Certificate Authority
Unabhängig davon, ob Sie eine möglichst realitätsnahe Testumgebung entwerfen, Checkmk im Intranet (besser) absichern oder eine interne…