Comment surveiller «https» à distance avec Icinga version 2?


9

J'ai icinga 2.3.11 sur Ubuntu 14.04.3 dans VirtualBox. Im essayant de surveiller le port "https" 443 par exemple " https://mail.google.com " ici. Ci-dessous est mon extrait de fichier host.conf par défaut

object Host "mailserver-01" {
    import "generic-host"
    address = "74.125.136.17"    /* ip for mail.google.com */ 
    vars.os = "Linux"
    vars.http_vhosts["http"] = {
        http_uri = "/"
    }
    vars.http_ssl = "1"
    vars.http_warn_time = "5"
    vars.http_critical_time = "10"

    vars.notification["mail"] = {
        groups = [ "icingaadmins" ]
    }
}

Ci-dessous, un extrait du fichier services.conf par défaut

apply Service "httpS" {
    import "generic-service"
    check_command = "http"
    assign where host.name == "mailserver-01"
}

Bien que le tableau de bord icingaweb2 affiche OK / vert, je ne sais pas s'il est correct

Réponses:


10

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.


2

J'ai googlé et trouvé la commande http dans

/usr/share/icinga2/include/command-plugins.conf

Dans cet exemple, j'ai essayé de surveiller https://mail.google.com ci-dessous 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"
}

Voici à quoi cela ressemble sur le tableau de bord icingaweb2 entrez la description de l'image ici

Exemple2

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"
}
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.