web-dev-qa-db-fra.com

Comment surveiller la télécommande "https" avec la version 2 de l'ICINGA?

J'ai ICINGA 2.3.11 sur Ubuntu 14.04.3 Inside Virtualbox. J'essaie de surveiller "HTTPS" Port 443 par exemple " https://mail.google.com " ICI.below 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" ]
    }
}

Vous trouverez ci-dessous un extrait de fichier par défaut.conf.

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

Bien que le tableau de bord Icingaweb2 affiche OK/Green, je ne sais pas si c'est correct

linuxubuntuubuntu-14.04icinga
9
satch_boogie

Votre hôte définit l'attribut personnalisé "http_vhosts" comme dictionnaire mais qui n'est jamais utilisé (il n'y a pas de demande de définition de la règle itératrice sur ce dictionnaire et des objets de service géréateur).

Au lieu de cela, la règle de service s'applique (sans une boucle) applique simplement le service "https". Par accident, l'attribut personnalisé hôte "http_ssl" est défini - il devrait lire true en tant que booléen au lieu d'un numéro sous forme de chaîne (c'est toujours vrai).

Vous voulez probablement vérifier plusieurs URI, pas seulement /.

Ma proposition (2 solutions):

1) Correction de votre service Appliquer la règle et supprimez les attributs personnalisés http_ * de la définition de votre objet hôte. Ajoutez-les au lieu de la règle de service de 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 comme paramètres de commande pour HTTP CheckCommand dans la documentation: http://docs.icinga.org/ ICINGA2/DERNIER/DOC/Module/ICINGA2/CHAPITRE/PLUGIN-CHECK-COMMANDES # PlugIn-Check-Command-http

2) Utilisez un service de service pour la règle et une boucle sur le dictionnaire http_vhosts défini à l'hôte.

vars.http_vhosts["https /"] = {
  http_ssl = true
  http_uri = "/"
}

Notez la nommée ici: "https /" sera le nom de 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 se produit à l'intérieur de la demande de règle: la clé de dictionnaire sera le nom du service. La valeur du dictionnaire est un dictionnaire imbriqué et contient http_uri et http_ssl sous forme de touches. Dans l'exemple qui s'appelle "config". Ce dictionnaire de configuration a la même structure exacte que l'attribut "Vars", c'est pourquoi nous pouvons simplement l'ajouter à l'intérieur du service, appliquer 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 de iCinga2 Daemon -c , puis regardez dans 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 que l'attribut personnalisé HTTP_VHOSTS défini générera ces objets de service, il n'y a pas besoin d'une expression "Attribuer où" (peut-être d'ajouter une idée d'être ignorée pour les exceptions). Avec la bonne stratégie, vous écrivez postuler pour des règles une seule fois, et n'ajoutez que de nouveaux hôtes avec un dictionnaire attribut personnalisé correspondant à l'avenir :-)

http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/monitoring-basics#OUX-Apply-for

Bien que la solution 2) nécessite des connaissances avancées sur la langue de configuration de l'ICINGA 2 et ses mots-clés, types de valeur et astuces magiques. Pourtant, nous pensons que de telles méthodes et meilleures pratiques aident à réduire la maintenance à long terme avec l'adoption et la modification de fichiers.

Vous pouvez également aller plus loin et utiliser des conditions if-else pour différents seuils basés sur le nom d'hôte. Ou utilisez des fonctions pour définir des seuils dynamiques en fonction des tempérités par exemple.

10
dnsmichi

J'ai Googled 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"
}

Ici à quoi il ressemble au tableau de bord icingaweb2 enter image description here

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"
}
2
satch_boogie