Im heutigen Teil 2 dieser Serie, befassen wir uns mit Konfiguration und deren Synchronisation zwischen Icinga 2 Instanzen in verteilten Umgebungen. Hierbei ist eine solche verteilte Umgebung schon gegeben, wenn der Agent zum Einsatz kommt, also immer wenn Endpoints und Zones beteiligt sind. In Teil 1 wurde Tipps zur Konfiguration der Verbindungsdaten gegeben, heute vertiefen wir, was auf dem Agenten passiert und was dort zusätzlich zum Icinga 2 Core benötigt wird.
Zuerst werden die jeweiligen Plugins auf den Agenten benötigt, seien es für Linux die Monitoring-Plugins oder auf der Windows-Seite die nativen aus dem Icinga-Projekt oder die Plugins vom NSClient++. Bei Icinga, auch in der neuen Version 2, ist das Objekt vom Typ CheckCommand das Bindeglied zwischen Host- bzw. Service-Objekt und dem konfigurierten Plugin, was zur Statusermittlung aufzurufen ist. Wobei ein lokal auszuführender Host-Check üblicherweise nicht Praxisrelevant ist. Das CheckCommand beschreibt wie das Plugin aufzurufen ist, den Ort im Dateisystem wie auch mit welchen Optionen das Plugin ausgeführt wird.
object CheckCommand "mem" {
command = [ PluginContribDir + "/check_mem.pl" ]
arguments = {
"-u" = {
set_if = "$mem_used$"
description = "Check USED memory"
}
...
Für die Pfadangabe zum Plugin ist immer die Verwendung einer Konstanten zu empfehlen, da sich der Ort von Plattform zu Plattform unterscheiden kann und eine Konstante ist für jede Instanz und damit für jeden Agenten gesondert setzbar. Standardmäßig sollten Konstanten in constants.conf im Icinga-Konfigurationsverzeichnis definiert werden.
Beim Plugin check_mem.pl im obigen Beispiel handelt es sich nicht um eines vom Monitoring-Plugin-Projekt, sondern um eines was gesondert auf den Agenten zu installieren ist. Ausserdem benötigen die Icinga-Instanzen der Agenten obige Definition. Für das CheckCommand mem wird diese schon in der ITL (Icinga Template Library) mit geliefert und muss nicht selbst erstellt werden. Auf den jeweiligen Agenten ist lediglich die Definition in icinga2.conf als include einzubinden. Sie befindet sich im PluginContrib-Bereich der ITL.
include <plugins> include <plugins-contrib>
In plugins hingegen befinden sich die Definitionen zu Plugins aus dem Monitoring-Projekt. Bei Windows empfiehlt sich die Definitionen der nativen (windows-plugins) bzw. NSClient++-Plugins (nscp) einzubinden.
Was aber nun, wenn man nun für ein Plugin selbst ein CheckCommand-Objekt anlegen muss? Es jeweils auf allen Agenten in die ITL legen? Nein, der ITL-Bereich ist ausschließlich für vom Projekt gepflegte Objekte, eigene würden beim nächsten Update wieder verschwinden. Ausserdem ist eine zusätzliche Pflege von sich ändernden Konfigurationsdateien für jeden Agenten nicht erstrebenswert. Hier kommen nun globale Zonen ins Spiel, die einem Konfiguration auf beliebige Endpoints synchronisieren und automatisch laden.
object Zone "linux-commands" {
global = true
}
object Zone "windows-commands" {
global = true
}
Im Gegensatz zum Server bzw. Master und Satelliten-Systemen, ist auf den Windows- und Linux-Agenten nur die entsprechende Zone in der zones.conf einzutragen. In beiden werden auch wirklich nur CheckCommands hinterlegt, Services und Templates werden in der Regel nicht auf Agenten benötigt und sind damit Informationen die besser nicht leicht zugänglich sowie zentral gehalten werden.
Windows kennt leider keinen graceful restart bzw. reload wie Unixsysteme und somit ist hier die Trennung sinnvoll, da Windows einen Stop des Dienstes und nachgelagertem Start nur ausführen muss, wenn es wirklich nötig ist.
Teil 3 dieser Reihe wird sich dann mit praktischen Definition von Services beschäftigen und wie diese ausschließlich aus den zugehörigen Host-Objekten parametresiert werden.
Besonders hervorzuheben sind im 0.5er Release der Webserver, der ssl gesichert und REST-apifiziert Kommandos entgegen nimmt und Informationen zurückliefert, Auch ist es in der aktuellen Version möglich Performancedaten direkt an graphite zu schreiben, was besonders in Großen Umgebungen zu einer starken Entlastung des monitoring servers (egal ob icinga 1 oder 2) führen kann. Um den überwachten Server besser zu schützen beendet NSClient jetzt alle von ihm angestoßenen Skripte wenn es selbst beendet wird, damit keine Langläufer mehr verloren gehen.
