Il tuo host definisce l'attributo personalizzato "http_vhosts" come dizionario, ma non viene mai utilizzato (non è possibile applicare l'iterazione definita da regole su quel dizionario e geberating oggetti di servizio).
Invece la regola di applicazione del servizio (senza un ciclo for) applica solo il servizio "httpS". Per sbaglio l'attributo personalizzato dell'host "http_ssl" è impostato - dovrebbe essere true come booleano invece di un numero come stringa (è sempre vero).
Probabilmente vorrai controllare più URI, non solo /.
La mia proposta (2 soluzioni):
1) Correggi la regola di applicazione del servizio e rimuovi gli attributi personalizzati http_* dalla definizione dell'oggetto host. Aggiungili invece alla regola di applicazione del servizio:
apply Service "httpS" {
import "generic-service"
check_command = "http"
vars.http_uri = "/"
vars.http_ssl = true
assign where host.name == "mailserver-01"
}
Puoi trovare tutti gli attributi personalizzati utilizzati come parametri di comando per http CheckCommand nella documentazione:http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/plugin-check-commands#plugin-check-command-http
2) Utilizza invece una regola di richiesta del servizio e ripeti il dizionario http_vhosts definito nell'host.
vars.http_vhosts["https /"] = {
http_ssl = true
http_uri = "/"
}
Nota la denominazione qui:"https /" sarà il nome del servizio generato. http_ssl e http_uri sono esattamente gli stessi nomi degli attributi personalizzati richiesti da http CheckCommand.
La magia avviene all'interno della regola di richiesta:la chiave del dizionario sarà il nome del servizio. Il valore del dizionario è un dizionario nidificato e contiene http_uri e http_ssl come chiavi. Nell'esempio che si chiama "config". Quel dizionario di configurazione ha la stessa identica struttura dell'attributo "vars", motivo per cui possiamo semplicemente aggiungerlo all'interno della richiesta di definizione del servizio.
apply Service for (servicename => config in host.vars.http_vhosts) {
import "generic-service"
check_command = "http"
vars += config
}
Verifica la configurazione usando icinga2 daemon -C e quindi esaminare gli oggetti di servizio generati per vedere quali attributi personalizzati vengono generati (elenco di oggetti icinga2).
Una cosa buona:tutti gli host che hanno definito l'attributo personalizzato http_vhosts genereranno questi oggetti di servizio, non c'è bisogno di un'espressione extea "assign where" (forse piuttosto aggiungi ignore where per le eccezioni). Con la giusta strategia scriverai applica per le regole solo una volta e in futuro aggiungerai solo nuovi host con dizionario di attributi personalizzati corrispondenti :-)
http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/monitoring-basics#using-apply-for
Sebbene la soluzione 2) richieda una conoscenza avanzata del linguaggio di configurazione icinga 2 e delle sue parole chiave, tipi di valore e trucchi magici. Tuttavia, riteniamo che tali metodi e best practice aiutino a ridurre la manutenzione a lungo termine con l'adozione e la modifica dei file.
Potresti anche andare oltre e utilizzare condizioni if-else per diversi threshokds in base al nome host. Oppure utilizza le funzioni per definire soglie dinamiche basate su periodi di tempo, ad esempio.
Ho cercato su Google e ho trovato il comando http in
/usr/share/icinga2/include/command-plugins.conf
In questo esempio ho provato a monitorare https://mail.google.comSotto c'è /etc/icinga2/conf.d/hosts.conf
object Host "www.google.com" {
address = "74.125.136.84"
check_command = "http"
vars.http_vhost = "mail.google.com"
vars.http_ssl = "1"
}
Ecco come appare sulla dashboard di icingaweb2 
Esempio2
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"
}