Migration von PRTG zu Icinga

Wir haben schon seit vielen Jahren Erfahrung mit der Migration von diversen Monitoringsystemen zu Icinga. Bei unseren Kunden stoßen wir hier zum einen auf ältere Nagios und Icinga-Umgebungen, aber auch auf Überwachungssoftware aus anderen Bereichen, wie z.B. Zabbix, CA Spectrum, Checkmk und Co.

Heute wollen wir euch zeigen, wie ihr eure PRTG Umgebung zu Icinga migrieren könnt. Dies ist kein detaillierter Guide, sondern soll euch einen Überblick über unsere Möglichkeiten geben.

Aus unserer Erfahrung empfehlen wir, die Migration nicht als reine 1:1-Übertragung zu betrachten. Vielmehr bietet der Wechsel die Chance, die bestehende Monitoring Umgebung zu analysieren und sich zu überlegen, wie das Monitoring in Zukunft aussehen soll.

Icinga verfolgt einen anderen Ansatz als PRTG – es gibt einem weniger mit an die Hand. Dies hat zur Folge, dass ihr euch im Vorfeld genauer Gedanken zu eurer Umgebung machen und am Ende des Tages mehr konfigurieren müsst. Sind ihr allerdings dazu bereit, dann erhaltet ihr ein System, dass auf genau eure Bedürfnisse angepasst ist. Icinga ist flexibel, skalierbar und modular.

Wir gehen wir generell eine Migration an?

Zunächst benötigen wir den Icinga-Master, unser zentrales System. Dieses besteht im Wesentlichen aus zwei Komponenten: dem Icinga Core und Icinga Web. Der Icinga Core ist das Herzstück von dem Monitoring-System. Er ist für die eigentliche Überwachung von den Hosts zuständig und übernimmt noch viele weiter der wesentlichen Aufgaben. Icinga Web ist die grafische Oberfläche von Icinga und dient der visuellen Darstellung der Hosts und Services. Hosts sind vergleichbar mit PRTG Devices und Services sind dann die jeweiligen Sensoren.

Weiterhin verwendet Icinga eine eigene Konfigurationssprache, um Hosts, Services, Benachrichtigungen und Abhängigkeiten zu definieren. Diese ist strukturiert und leistungsstark, erfordert jedoch eine gewisse Einarbeitung – insbesondere, wenn ihr von einem GUI-basierten Tool wie PRTG kommt. Aber keine Panik, es gibt ein Icinga Web Module, was dieses „Problem“ löst. Der Icinga Director ermöglicht die Konfiguration von Icinga Objekten über die Weboberfläche und erstellt für sie die valide Icinga Konfiguration in der Icinga DSL. Dennoch bleibt es notwendig, die grundlegenden Konzepte von Icinga zu verstehen, um den Director effektiv zu nutzen, da alle Objekte selbst angelegt werden müssen.

Dies ist der Grund, warum in den allermeisten Umgebungen der Director zum Einsatz kommt. Vor allem im Falle der Migration von PRTG zu Icinga empfehlen wir die Installation vom Director, da so weiterhin die Bedienung über die Weboberfläche erfolgen kann.

Was können wir aus PRTG auslesen und für Icinga automatisiert übernehmen?

Wie bekommen wir nun bestehende Systeme in Icinga migriert? Hier machen wir uns die Automatisierungsfunktion des Directors zu Nutze. Dieser ermöglicht es, verschiedenste Datenquellen abzufragen, wie zum Beispiel Datenbanken, REST-API, CSV-Dateien und vieles mehr. Die gewonnenen Daten können wir anschließend verwenden, um daraus Icinga-Konfiguration zu erstellen.

Die Daten für die Migration zu Icinga können über die HTTP-API von PRTG ausgelesen werden. Dort können wir Informationen zu Devices, Sensoren, Probes und weiteren relevanten Objekten auslesen.

Hier einmal exemplarisch, wie wir ein Device aus PRTG nach Icinga migrieren und ein einfaches Monitoring dafür erstellen:

Abfrage der Devices:

curl https://thriving-giraffe.my-prtg.com/api/table.json?content=devices&colums=group,device,host&apitoken=supersecuretoken

{
...
    {
      "group": "Linux-Servers",
      "group_raw": "Linux-Servers",
      "device": "NETWAYS-001",
      "device_raw": "NETWAYS-001",
      "host": "91.198.20.153",
      "host_raw": "91.198.20.153"
    },
...
    {
      "group": "Linux-Servers",
      "group_raw": "Linux-Servers",
      "device": "NETWAYS-001",
      "device_raw": "NETWAYS-001",
      "sensor": "SSH Disk Free",
      "sensor_raw": "SSH Disk Free"
    },
...
}

Import in den Director:

Die gewonnenen Devices werden über den Import-Mechanismus des Directors in Icinga übertragen. Daraus werden dann Hosts erstellt. Diese sehen wie folgt aus:

object Host "netways-001.foo-bar.de" {
    display_name = "NETWAYS-001"
    address = "91.198.20.153"
    check_command = "hostalive"
    vars.group = "Linux-Servers"
}

Service-Zuweisung:

Über Service Sets werden den Hosts automatisch die passenden Services zugewiesen – z.B. CPU-Last, Speicherplatz oder Netzwerkstatus.

Im Director könnt ihr Service Sets erstellen. Das sind Gruppen von Services, die anhand von Apply Rules an einen Host anhängen werden können.

Noch mal kurz als Erinnerung: Services sind so was wie Sensoren. Service Sets sind vor allem praktisch, um ein einfaches Monitoring für einen Host bereitzustellen. Für dieses Beispiel wurde ein einfaches Server-Service-Set erstellt, das die CPU, Disk, Memory und Updates checkt. Mit der Variable vars.group = Linux-Servers legen wir fest, welche Hosts dieses Service-Set bekommen.

Was genau müssen wir dann noch nachziehen?

An dieser Stelle ist die Konfiguration abgeschlossen, aber die Überwachung wird noch nicht funktionieren. Icinga setzt nämlich auf ein agenten-basiertes Monitoring, was bedeutet, dass zunächst der Icinga Agent auf den zu überwachenden Hosts installiert werden muss. Es gibt zwar andere Möglichkeiten, die Systeme zu überwachen, aber der empfohlene Weg ist der Einsatz des Icinga Agents. Dieser ist hauptsächlich dafür verantwortlich, die Checks auf dem System auszuführen.

Vielleicht fragen ihr euch, warum ihr auf ein agenten-basiertes Monitoring wechseln sollten. Hier ein paar Vorteile genannt:

Die einzelnen Überprüfungen, also die Checks, werden auf dem zu überwachenden Host selbst ausgeführt. Das hat den Vorteil, dass die Last ausgelagert wird. Und das ist vor allem dann wichtig, wenn ihr eine größere Umgebung mit mehreren Tausenden Services habt, die alle paar Minuten ausgeführt werden.

Außerdem wird nur eine einzige Verbindung zwischen dem Icinga Master und dem Agenten aufgebaut. Damit die Verbindung sicher ist, setzt Icinga auf Zertifikate. Das heißt, die Verbindung ist verschlüsselt und authentifiziert.

Der Icinga Agent kann auch als sogenannter Satellit verwendet werden. In diesem „Modus“ ist der Agent quasi ein Relay. Das ist wichtig, wenn der Icinga Master nicht an jeden Host kommt, wenn ihr eine verteilte Umgebung habt.

Die Installation eines Agenten wirkt für euch vielleicht erst mal nach viel Arbeit, aber keine Sorge, die Installation des Icinga Agent kann sehr gut automatisiert werden. Ihr könnt euch selbst ein kleines Script schreiben oder ihr greift auf bestehende Lösungen wie die Ansible-Collection für Icinga zurück.

Nach Installation des Agents ist die Migration des Hosts abgeschlossen und im Icinga Web zu sehen:

Wir hoffen, ihr konntet diesem Blogpost ein wenig entnehmen, was bei der Migration von PRTG zu Icinga auf euch zukommt und wie dies in etwa aussehen könnte.

Unterstützung durch NETWAYS

Benötigt ihr Hilfe mit der Migration, helfen wir bei NETWAYS gerne dabei. Ihr könnt bei uns alles von Schulungen, Betriebsunterstützung, Support und Consulting rund um das Theme Icinga buchen.

Füllt einfach unser Formular aus und tretet ganz unverbindlich mit und in Kontakt! Wir freuen uns auf eure Nachricht!