Su host define el atributo personalizado "http_vhosts" como diccionario, pero nunca se usa (no se aplica una regla definida iterando sobre ese diccionario y generando objetos de servicio).
En cambio, la regla de aplicación del servicio (sin un bucle for) solo aplica el servicio "httpS". Por accidente, se establece el atributo personalizado de host "http_ssl"; debería decir true como booleano en lugar de un número como cadena (eso siempre es cierto).
Probablemente desee verificar varias URI, no solo /.
Mi propuesta (2 soluciones):
1) Corrija su regla de aplicación de servicio y elimine los atributos personalizados http_* de su definición de objeto de host. En su lugar, agréguelos a la regla de aplicación del servicio:
apply Service "httpS" {
import "generic-service"
check_command = "http"
vars.http_uri = "/"
vars.http_ssl = true
assign where host.name == "mailserver-01"
}
Puede encontrar todos los atributos personalizados utilizados como parámetros de comando para http CheckCommand en la documentación:http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/plugin-check-commands#plugin-check-command-http
2) En su lugar, use una regla de solicitud de servicio y recorra el diccionario http_vhosts definido en el host.
vars.http_vhosts["https /"] = {
http_ssl = true
http_uri = "/"
}
Tenga en cuenta el nombre aquí:"https /" será el nombre del servicio generado. http_ssl y http_uri son exactamente los mismos nombres que los atributos personalizados requeridos por http CheckCommand.
La magia ocurre dentro de la regla de solicitud:la clave del diccionario será el nombre del servicio. El valor del diccionario es un diccionario anidado y contiene http_uri y http_ssl como claves. En el ejemplo que se llama "config". Ese diccionario de configuración tiene exactamente la misma estructura que el atributo "vars", por lo que podemos agregarlo dentro del servicio de solicitud de definición.
apply Service for (servicename => config in host.vars.http_vhosts) {
import "generic-service"
check_command = "http"
vars += config
}
Verifique la configuración usando icinga2 daemon -C y luego busque en los objetos de servicio generados para ver qué atributos personalizados se generan (lista de objetos icinga2).
Una cosa buena:todos los hosts que tienen definido el atributo personalizado http_vhosts generarán estos objetos de servicio, no hay necesidad de una expresión extea "asignar dónde" (tal vez más bien agregue ignorar dónde para las excepciones). Con la estrategia correcta, escribirá la aplicación de reglas solo una vez y solo agregará nuevos hosts con el diccionario de atributos personalizado coincidente en el futuro :-)
http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/monitoring-basics#using-apply-for
Aunque la solución 2) requiere conocimientos avanzados sobre el lenguaje de configuración icinga 2 y sus palabras clave, tipos de valores y trucos de magia. Sin embargo, creemos que tales métodos y mejores prácticas ayudan a reducir el mantenimiento a largo plazo con la adopción y el cambio de archivos.
También puede ir más allá y usar condiciones if-else para diferentes umbrales según el nombre de host. O use funciones para definir umbrales dinámicos basados en períodos de tiempo, por ejemplo.
Busqué en Google y encontré el comando http en
/usr/share/icinga2/include/command-plugins.conf
En este ejemplo, he intentado monitorear https://mail.google.comAbajo está /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"
}
Así es como se ve en el tablero de icingaweb2 
Ejemplo2
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"
}