Ihr Host definiert das benutzerdefinierte Attribut "http_vhosts" als Wörterbuch, aber das wird nie verwendet (es gibt keine Anwendung für regeldefiniertes Iterieren über dieses Wörterbuch und Generieren von Dienstobjekten).
Stattdessen wendet die Dienstanwendungsregel (ohne For-Schleife) nur den Dienst "httpS" an. Aus Versehen ist das benutzerdefinierte Host-Attribut "http_ssl" gesetzt - es sollte true lauten als Boolean statt einer Zahl als String (das ist immer wahr).
Wahrscheinlich möchten Sie mehrere URIs prüfen, nicht nur /.
Mein Vorschlag (2 Lösungen):
1) Korrigieren Sie Ihre Dienstanwendungsregel und entfernen Sie die benutzerdefinierten http_*-Attribute aus Ihrer Hostobjektdefinition. Fügen Sie sie stattdessen der Dienstanwendungsregel hinzu:
apply Service "httpS" {
import "generic-service"
check_command = "http"
vars.http_uri = "/"
vars.http_ssl = true
assign where host.name == "mailserver-01"
}
Sie können alle benutzerdefinierten Attribute finden, die als Befehlsparameter für http verwendet werden CheckCommand in der Dokumentation:http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/plugin-check-commands#plugin-check-command-http
2) Verwenden Sie stattdessen einen Service apply for rule und durchlaufen Sie das http_vhosts-Wörterbuch, das auf dem Host definiert ist.
vars.http_vhosts["https /"] = {
http_ssl = true
http_uri = "/"
}
Beachten Sie hier die Benennung:"https /" ist der generierte Dienstname. http_ssl und http_uri sind genau die gleichen Namen wie die erforderlichen benutzerdefinierten Attribute durch den http CheckCommand.
Die Magie passiert innerhalb der Apply-for-Regel: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 "vars"-Attribut, weshalb wir es einfach innerhalb des Dienstantrags zur Definition hinzufügen können.
apply Service for (servicename => config in host.vars.http_vhosts) {
import "generic-service"
check_command = "http"
vars += config
}
Überprüfen Sie die Konfiguration mit icinga2 daemon -C und schauen Sie dann in die generierten Dienstobjekte, um zu sehen, welche benutzerdefinierten Attribute generiert werden (icinga2-Objektliste).
Eine gute Sache - alle Hosts, die das benutzerdefinierte Attribut http_vhosts definiert haben, werden diese Dienstobjekte generieren, es besteht keine Notwendigkeit für einen extea "assign where"-Ausdruck (vielleicht fügen Sie lieber "ignore where" für Ausnahmen hinzu). Mit der richtigen Strategie schreiben Sie Regeln nur einmal anwenden und fügen in Zukunft nur noch neue Hosts mit passendem benutzerdefinierten Attributwörterbuch hinzu :-)
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önnten auch weiter gehen und if-else-Bedingungen für verschiedene Threshokds basierend auf dem Hostnamen verwenden. Oder verwenden Sie Funktionen, um beispielsweise dynamische Schwellenwerte basierend auf Zeiträumen zu definieren.
Ich habe gegoogelt und den http-Befehl in
gefunden/usr/share/icinga2/include/command-plugins.conf
In diesem Beispiel habe ich versucht, https://mail.google.comUnten ist /etc/icinga2/conf.d/hosts.conf
zu überwachenobject Host "www.google.com" {
address = "74.125.136.84"
check_command = "http"
vars.http_vhost = "mail.google.com"
vars.http_ssl = "1"
}
So sieht es auf dem icingaweb2-Dashboard aus
Beispiel2
object Host "secure.example.com" {
address = "14.28.83.22"
check_command = "http"
vars.http_vhosts["secure.example.com"] = {
http_uri = "/merchant/login.aspx"
}
vars.notification["mail"] = {
groups = [ "icingaadmins" ]
}
vars.http_ssl="1"
}