Ihr Host definiert das benutzerdefinierte Attribut "http_vhosts" als Wörterbuch, das jedoch nie verwendet wird (es gilt nicht für Regeln, die über dieses Wörterbuch iterieren und Serviceobjekte geberieren).
Stattdessen wendet die Dienstanwendungsregel (ohne for-Schleife) nur den Dienst "httpS" an. Aus Versehen wird das benutzerdefinierte Hostattribut "http_ssl" festgelegt - es sollte true als Boolescher Wert anstelle einer Zahl als Zeichenfolge lauten (das ist immer true).
Sie möchten wahrscheinlich mehrere URIs überprüfen, nicht nur /.
Mein Vorschlag (2 Lösungen):
1) Korrigieren Sie Ihre Dienstanwendungsregel und entfernen Sie die benutzerdefinierten Attribute http_ * aus Ihrer Hostobjektdefinition. Fügen Sie sie stattdessen der Service Apply-Regel hinzu:
apply Service "httpS" {
import "generic-service"
check_command = "http"
vars.http_uri = "/"
vars.http_ssl = true
assign where host.name == "mailserver-01"
}
Alle benutzerdefinierten Attribute, die als Befehlsparameter für den http CheckCommand verwendet werden, finden Sie in der Dokumentation: http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/plugin-check-commands#plugin-check- Befehl-http
2) Verwenden Sie stattdessen eine Dienstanwendungsregel und durchlaufen Sie das auf dem Host definierte http_vhosts-Wörterbuch.
vars.http_vhosts["https /"] = {
http_ssl = true
http_uri = "/"
}
Beachten Sie die Benennung hier: "https /" ist der generierte Dienstname. http_ssl und http_uri sind genau dieselben Namen wie die erforderlichen benutzerdefinierten Attribute des http CheckCommand.
Die Magie geschieht innerhalb der Regel zum Beantragen: Der Wörterbuchschlüssel ist der Dienstname. Der Wörterbuchwert ist ein verschachteltes Wörterbuch und enthält http_uri und http_ssl als Schlüssel. Im Beispiel heißt das "config". Dieses Konfigurationswörterbuch hat genau die gleiche Struktur wie das Attribut "vars", weshalb wir es einfach innerhalb des Dienstes hinzufügen können, um die Definition zu beantragen.
apply Service for (servicename => config in host.vars.http_vhosts) {
import "generic-service"
check_command = "http"
vars += config
}
Überprüfen Sie die Konfiguration mit dem icinga2-Daemon -C und überprüfen Sie anschließend die generierten Serviceobjekte, um festzustellen, welche benutzerdefinierten Attribute generiert werden (icinga2-Objektliste).
Eine gute Sache: Alle Hosts, für die das benutzerdefinierte Attribut http_vhosts definiert ist, generieren diese Serviceobjekte. Es ist kein extea-Ausdruck "zuweisen, wo" erforderlich (möglicherweise wird für Ausnahmen lieber "Ignorieren" hinzugefügt). Mit der richtigen Strategie werden Sie nur einmal Regeln anwenden und in Zukunft nur noch neue Hosts mit passendem benutzerdefinierten Attributwörterbuch hinzufügen :-)
http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/monitoring-basics#using-apply-for
Lösung 2) erfordert jedoch fortgeschrittene Kenntnisse über die Konfigurationssprache icinga 2 und ihre Schlüsselwörter, Werttypen und Zaubertricks. Wir sind jedoch der Meinung, dass solche Methoden und Best Practices dazu beitragen, die langfristige Wartung durch das Übernehmen und Ändern von Dateien zu reduzieren.
Sie können auch weiter gehen und if-else-Bedingungen für verschiedene Schwellenwerte basierend auf dem Hostnamen verwenden. Oder verwenden Sie Funktionen, um dynamische Schwellenwerte zu definieren, die beispielsweise auf Zeitperioden basieren.