Votre hôte définit l'attribut personnalisé "http_vhosts" comme dictionnaire, mais il n'est jamais utilisé (il n'y a pas de demande pour l'itération définie par la règle sur ce dictionnaire et la géberation des objets de service).
Au lieu de cela, la règle d'application de service (sans boucle for) applique simplement le service "httpS". Par accident, l'attribut personnalisé de l'hôte "http_ssl" est défini - il doit lire true comme booléen au lieu d'un nombre sous forme de chaîne (c'est toujours vrai).
Vous voulez probablement vérifier plusieurs URI, pas seulement /.
Ma proposition (2 solutions):
1) Corrigez votre règle d'application de service et supprimez les attributs personnalisés http_ * de votre définition d'objet hôte. Au lieu de cela, ajoutez-les à la règle d'application du service:
apply Service "httpS" {
import "generic-service"
check_command = "http"
vars.http_uri = "/"
vars.http_ssl = true
assign where host.name == "mailserver-01"
}
Vous pouvez trouver tous les attributs personnalisés utilisés en tant que paramètres de commande pour http CheckCommand dans la documentation: http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/plugin-check-commands#plugin-check- commande-http
2) Utilisez plutôt un service de demande de règle et faites une boucle sur le dictionnaire http_vhosts défini sur l'hôte.
vars.http_vhosts["https /"] = {
http_ssl = true
http_uri = "/"
}
Notez le nom ici: "https /" sera le nom du service généré. http_ssl et http_uri sont exactement les mêmes noms que les attributs personnalisés requis par http CheckCommand.
La magie opère à l'intérieur de la règle de demande: la clé du dictionnaire sera le nom du service. La valeur du dictionnaire est un dictionnaire imbriqué et contient http_uri et http_ssl comme clés. Dans l'exemple qui s'appelle "config". Ce dictionnaire de configuration a exactement la même structure que l'attribut "vars", c'est pourquoi nous pouvons simplement l'ajouter à l'intérieur du service appliquer pour la définition.
apply Service for (servicename => config in host.vars.http_vhosts) {
import "generic-service"
check_command = "http"
vars += config
}
Vérifiez la configuration à l'aide du démon icinga2 -C , puis examinez les objets de service générés pour voir quels attributs personnalisés sont générés (liste d'objets icinga2).
Une bonne chose - tous les hôtes qui ont l'attribut personnalisé http_vhosts défini généreront ces objets de service, il n'y a pas besoin d'une expression extea "assign where" (peut-être plutôt ajouter ignore where où pour les exceptions). Avec la bonne stratégie, vous écrirez appliquer les règles une seule fois et n'ajouterez que de nouveaux hôtes avec le dictionnaire d'attributs personnalisé correspondant à l'avenir :-)
http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/monitoring-basics#using-apply-for
Bien que la solution 2) nécessite des connaissances avancées sur le langage de configuration icinga 2 et ses mots-clés, types de valeur et astuces magiques. Pourtant, nous pensons que ces méthodes et meilleures pratiques contribuent à réduire la maintenance à long terme avec l'adoption et la modification des fichiers.
Vous pouvez également aller plus loin et utiliser des conditions if-else pour différents threshokds en fonction du nom d'hôte. Ou utilisez des fonctions pour définir des seuils dynamiques basés sur des périodes de temps par exemple.
