Auch wenn es viele fancy Monitoring Dashboards gibt, finde ich Icinga2 immer noch am besten: es ist flexibel, hat eine erstaunliche Entwicklung im letzten Jahr durchgemacht und ist leicht in großen wie kleinen Umgebungen einsetzbar: jetzt auch wesentlich einfacher mit einer Konfigurations-GUI genannt Icinga2 Director.
Generell würde ich bei großen Umgebungen empfehlen, diese neu mit dem Icinga2 Director aufzubauen. So wie ich die IT-Systemlandschaften bisher in Firmen kennengelernt habe, ist ein Reboot / Relaunch mancher Services einfacher als sich frustriert durch den angestaubten Müll zu wühlen. Nichts desto trotz ist ein Import der bisherigen Hosts, Services und Commands möglich und funktioniert (zumindest bei meinen kleinen Umgebungen).
Ich arbeite mit einem Debian 9 System. Andere Distributionen werden ähnlich funktionieren
Installation
Die offizielle Director Dokumentation sagt euch alles, was an Requirements zu erfüllen ist. In Kürze:
- PHP-Pakete und Module für Icinga installieren, die der Director braucht (nur die Releases entpacken!).
- Eine extra Datenbank anlegen.
Nach der Installation des Directors wird das Modul im Web Backend aktiviert. Dort wird die neu angelegte Datenbank samt Verbindungsinformationen angelegt.
API
Danach aktiviere das api Modul von Icinga (icinga2 feature enable api) und führe das Setup der API aus, indem du folgenden Befehl verwendest:
icinga2 api setup
Nun kann icinga2 neu gestartet werden und Icinga sollte einen neuen Port nach außen geöffnet haben: 5665. Denkt an eure Firewallsettings, sofern ihr nicht möchtet, dass eure Icinga API weltweit offen ist!
Endpoint und Zone
Abschließend muss noch der Endpoint definiert werden, da der Director nicht direkt mit Icinga spricht, sondern über die API geht. Diese wird in der zones.conf eingerichtet.
Zuvor legen wir aber für den director einen eigenen API User an (unter /etc/icinga2/features-enabled/api.conf):
object ApiUser "director" {
password = "sicherespasswort"
permissions = [ "*" ]
}
Nun braucht es noch unter /etc/icinga2/zones.conf folgenden Eintrag:
object Zone "director-global" {
global = true
}
Damit kann icinga2 nochmal durchgestartet werden und im Web Backend wird nun unter Konfiguration => Module => Director die API Verbindung eingerichtet. Einziger Knackpunkt ist der Name des Endpoints. Das ist immer der volle Hostname (/etc/hosts), sofern nicht anders in der zones.conf definiert – wenn ihr hier folgende Einträge findet:
object Endpoint NodeName {
host = NodeName
}
object Zone ZoneName {
endpoints = [ NodeName ]
}
Mit Klick auf Import ausführen werden nun alle Befehle und User, die bereits angelegt wurden als ausstehende Änderung vom Director als zu Deployen angezeigt. Keine Sorge, das heißt nur, dass diese Konfigurationen dann für den Director bereit stehen – nicht doppelt ausgeführt werden. Wenn ihr also bisher mit eigenen Konfigs Hosts und Services laufen habt, werden diese nicht automatisch importiert, sondern laufen parallel zu euren über den Director vorgenommenen Konfigurationen.
Daemon
Der Icinga Director braucht darüber hinaus einen eigenen Daemon – dieser ist schnell und einfach installiert. Beachtet bitte vor dem Start des Daemons, dass das Paket icingacli auch wirklich auf eurem Server installiert ist:
apt-get install icingacli
Beachtet außerdem, dass ihr in der Datei /etc/systemd/system/icinga-director.service einen User setzt, der unter /etc/icingaweb2 lesen und schreiben darf.
Grundlagen
Ich habe den Director noch nicht ganz durchschaut, aber in Kürze für diesen Artikel ein paar Grundlagen im Umgang – zumindest laut meinen 5ct.
Datenfelder
Viele Check Plugins benötigen API Kennworte, Ports, Disk Arrays etc. Damit ihr diese freien Felder entweder beim Anlegen der Services oder Hosts vorfindet, müsst ihr sie im vorhinein definieren: unter Icinga Director (Hauptmenüpunkt) findet ihr ganz unten Datenfelder definieren. Feldname muss sich mit dem Namen der Variable eures Check Plugins decken!
Außerdem ist es möglich, diese Datenfelder direkt bei der Vorschau von Befehlen anzulegen: unter Kommandos => Externe Kommandos klickt auf einen Befehl und dann auf den Reiter Felder. Dort habt ihr die komplette Auswahl aller nötigen Variablen. Das anlegen aller Variablen für jeden Befehl ist nicht nötig, z.B. wird $address$ weiterhin wie gehabt automatisch umgesetzt.
Service- / Hostvorlagen
Damit ihr überhaupt neue Services und Hosts anlegen könnt, müsst ihr zunächst Service und Hostvorlagen erstellen. Hier geht es überwiegend darum, dass ihr den Container für die einzelnen Elemente definiert, z.B.: Checkintervall, aktive / passive Checks, Checktimeout etc.
Hier ist es wichtig, dass ihr euch zuvor ein klares System zurecht legt, denn die Einstellungen der Vorlagen doppeln sich hier bei Hosts und Services. Wichtig sind vor allem die Einstellungen zu:
- Cluster-Zone (eigentlich immer Icinga Director) und
- als Icinga Agent ausführen (was dann z.B. für Remote Windows checks relevant ist)
Bei Hosts braucht ihr zuvor auch noch eine Hostgruppe.
Deployments
Jede Änderung, die ihr vornehmt, ist nicht sofort live, sondern muss erst im Reiter Aktivitätslog ausgerollt werden. Sollten Fehler vorliegen, wird die Änderung nicht ausgerollt und Icinga läuft trotzdem ganz normal weiter. Das ist schonmal ein großer Fortschritt im Gegensatz zum alten Modell.
Wenn ihr Änderungen an internen Dateien, wie z.B. commands.conf vornehmt, müsst ihr den initialen Import erneut starten – dieser funktioniert inkrementell: zu finden unter Icinga Director => Icinga Infrastruktur => Kickstart Assistent.
