Icinga 2 Best Practice Teil 6: Service-Checks auf Agenten schedulen

In Teil 1 dieser Blogserien beschäftigten wir uns mit Zonen, Agenten und wie man zentral angetriggert Plugins auf diesen Agenten ausführt. Nun im aktuellen Teil soll es darum gehen, das einplanen und ausführen dem Agenten selbst zu überlassen, damit werden auch während eines Verbindungsausfalls weiter Daten gesammelt und später, wenn die Verbindung wieder besteht, nachträglich übertragen.
In dem hier folgenden verdeutlichen wir, wie dies zu konfigurieren ist, mit einem Beispiel von einer Zone master, einer globalen Zone global-templates und einer Zone zu einem Beispiel Agenten agent.example.org.
Die Zonen- und Endpoint-Definitionen des Agenten auf Seite des Masters müssen in einer Datei in der Master-Zone oder in zones.conf hinterlegt werden. Leider ist es hier nicht möglich die jeweiligen Host-, Zonen- und Endpoint-Objekte in einer Datei zusammen zufassen, da wir das Host-Objekt agent.example.org zum Agenten selbst synchronisieren müssen und diese Definition in der Agenten-Zone abgelegt sein muss, z.B. in der Datei zones.d/agent.example.org/agent.conf:

object Host "agent.example.org“ {
 import "generic-host"
 address = "10.0.10.42"
 zone = get_object(Zone, name).parent
 vars.os = "Linux“
}

Durch die Ablage an genau diesem Ort, wird das Objekt zum Agenten synchronisiert. Mit setzen des Attributes zone auf die eigene Parent-Zone sorgen wir jedoch wieder dafür, dass das Host-CheckCommand sowie alle an diesen Host gebundenen Services auf einem Endpoint der Parent-Zone ausgeführt werden, hier die Zone master.
Damit wird der hostalive vom Master ausgeführt, was gewünscht ist, da sonst der Host seine Erreichbarkeit von sich selbst aus testen würde. D.h. alle Services, die auf den Agenten über das Netzwerk zugreifen sollen, bleiben wie sie sind und wir müssen keine Anpassungen vornehmen. Ganz im Gegensatz zu Services, die ein Plugin lokal auf dem Agenten ausführen sollen.

apply Service "load“ {
 import "generic-service“
 check_command = "load“
 if ( get_object(Zone, host.name) ) {
   zone = host.name
 }
 assign where host.vars.os == "Linux"
}

Auch Objekte vom Typ Service besitzen das Attribut zone mit dem wir hier nun die umgekehrten Weg beschreiten, existiert zum Host eine Zone selben Namens, wird die Zone zur Ausführung des zugeordneten Plugins in die eigene Agenten-Zone verlegt.