Su host define el atributo personalizado "http_vhosts" como diccionario, pero eso nunca se usa (no se aplica la iteración definida por reglas sobre ese diccionario y los objetos de servicio geberating).
En cambio, la regla de aplicación del servicio (sin un bucle for) simplemente aplica el servicio "httpS". Por accidente, se establece el atributo personalizado del host "http_ssl": debería leer verdadero como booleano en lugar de un número como cadena (eso siempre es cierto).
Probablemente desee verificar múltiples URI, no solo
Mi propuesta (2 soluciones):
1) Arregle 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- comando-http
2) Utilice un servicio de solicitud de regla en su lugar y repita 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 y solicitar la definición.
apply Service for (servicename => config in host.vars.http_vhosts) {
import "generic-service"
check_command = "http"
vars += config
}
Verifique la configuración con icinga2 daemon -C y luego mire los objetos de servicio generados para ver qué atributos personalizados se generan (lista de objetos icinga2).
Una cosa buena: todos los hosts que tengan definido el atributo personalizado http_vhosts generarán estos objetos de servicio, no hay necesidad de una expresión extea de "asignar dónde" (quizás agregue ignorar dónde para excepciones). Con la estrategia correcta, escribirá solicitar las reglas solo una vez, y solo agregará nuevos hosts con un diccionario de atributos personalizados 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 de icinga 2 y sus palabras clave, tipos de valor 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 podría ir más allá y usar condiciones if-else para diferentes umbrales basados en el nombre del host. O utilice funciones para definir umbrales dinámicos basados en períodos de tiempo, por ejemplo.
