Forum Linux.général Forcer une notification OK dans Shinken/Nagios

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
3
27
juin
2013

Bonjour cher forum,

J'utilise actuellement Nagios (et Shinken en test) pour superviser le fonctionnement d'une machine.
Sur certaines tranches horaires, la "surveillance" de l'équipement est à la charge de personnel "non technique". Ces personnes veulent recevoir un rapport régulier de la machine MEME QUAND TOUT VA BIEN.
Pour le moment, on utilise un script de check "menteur" qui indique au minimum un warning, mais je ne trouve pas ça très élégant.
Y a t'il donc un moyen de force une notification périodique même sur un status OK.

Merci d'avance mon cher forum

  • # contre productif

    Posté par  (site web personnel) . Évalué à 3.

    C'est pas fait pour, la supervision est faite pour remonter les erreurs, c'est le meilleur moyen de louper une alerte réelle. (trop d'infos tue l'info )

    Système - Réseau - Sécurité Open Source

    • [^] # Re: contre productif

      Posté par  . Évalué à 4.

      « Dis moi de quoi tu as besoin je te dirai comment t'en passer » ?

      Tu l'aides pas là :)

      Le fait est qu'il a une demande d'utilisateurs qu'il peut pas trop refuser à priori.

      Je me permet de ramener mon grain de sel car il est possible qu'on me fasse le même genre de demande dans pas longtemps…

    • [^] # Re: contre productif

      Posté par  . Évalué à 3.

      Oui sauf que c'est encore le meilleur moyen de vérifier que tout la chaîne d'information fonctionne. Car en cas de problème sur la passerelle SMTP ou autre connerie de genre … tu passes à côté (c'est le raisonnement des utilisateurs qui n'est pas complètement idiot).
      De plus, les utilisateurs en question n'ont qu'une seul installation à superviser de la sorte et les enjeux sont importants.

      Mais je suis d'accord avec toi : trop d'info tue l'info, seulement on ne me laisse pas le choix. Mais je trouve "étrange" que cette fonction n'existe pas / ne soit pas documentée.

      • [^] # Re: contre productif

        Posté par  . Évalué à 6.

        Et puis une supervision est faite, à mon sens, pour superviser …. même quand tout fonctionne normalement non ?

  • # Nagstamon

    Posté par  . Évalué à 4.

    Avec un outil comme nagstamon, et un filtre sur cet hôte uniquement?

    • [^] # Re: Nagstamon

      Posté par  . Évalué à 1.

      Je connaissais pas nagstamon, mais nagvis est pas mal et pluggable aux 2 solutions Nagios et Shinken.
      Faire une map avec une machine par composant checké ? si c'est que pour la surveillance d'1 seule machine.

  • # Warning

    Posté par  . Évalué à 4.

    Pour le moment, on utilise un script de check "menteur" qui indique au minimum un warning, mais je ne trouve pas ça très élégant.

    Avertissement : Il n'y a aucune erreur, c'est louche, contacter votre admin, peut-être que tout est cassé ! :)

    Bon, blague à part, leur demande est quand même recevable. Ton personnel non-technique ce ne serait pas des qualiticiens par hasard ?

    • [^] # Re: Warning

      Posté par  . Évalué à 1.

      Avertissement : Il n'y a aucune erreur, c'est louche, contacter votre admin, peut-être que tout est cassé ! :)

      Pour le coup ça serait plutôt: "Attention !!! Je vous avertis que tout va bien en affichant de l'orange partout car je ne peux pas vous le dire normalement." :-)

      Sinon le public visé sont des personnes qui ne connaissent rien à la machine en question (car ce n'est pas leur boulot) et qui doivent juste appeler une équipe technique en cas de problème.

      • [^] # Re: Warning

        Posté par  . Évalué à 5.

        un acces sur l'interface web, des couleurs pour dire que tout va bien

        pour verifier que tout va bien suffit d'ouvrir le navigateur

        • [^] # Re: Warning

          Posté par  (site web personnel) . Évalué à 2.

          +1, quand tout est au "vert" tout va bien.

          Système - Réseau - Sécurité Open Source

          • [^] # Re: Warning

            Posté par  . Évalué à 1.

            Je suis d'accord ça serait une super solution dans le meilleur des mondes … Le problème c'est qu'il est impossible de fournir l'accès à Nagios car les utilisateurs ne sont pas sur notre réseau.
            Le mail est malheureusement le seul lien que l'on puisse avoir.

            • [^] # Re: Warning

              Posté par  (site web personnel) . Évalué à 2.

              par tunnel, https, c'est pas possible ?

              Système - Réseau - Sécurité Open Source

            • [^] # Re: Warning

              Posté par  . Évalué à 3.

              Sur certaines tranches horaires, la "surveillance" de l'équipement est à la charge de personnel "non technique". Ces personnes veulent recevoir un rapport régulier de la machine MEME QUAND TOUT VA BIEN.

              bah demande leur de tester le service.

              si c'est un service telephonique, il passe un appel,
              si c'est un service web, il se connecte dessus.

              de toute facon, si tu leur envoie un email toutes les heures, il faudra bien qu'il regarde leur email toutes les heures+5 minutes pour savoir s'ils ont recu le message qui dit que tout va bien.

              mais je ne comprend pas l'interet, car s'ils ne l'ont pas recu, c'est :

              • soit que le monitoring est mort
              • soit qu'un element du reseau entre ton nagios et leur boite email est mort (un routeur, un lien reseau, un filtre antispam un peu sensible)

              et comme tu viens de dire qu'il ne pouvait pas acceder directement à la plateforme de surveillance (le nagios), je suppose qu'il y a plusieurs intermediaires entre toi et eux, donc autant de chance que l'email se perde.

  • # Livestatus

    Posté par  (Mastodon) . Évalué à 4.

    Lancer une requête Livestatus, récupérer le résultat et placer ça dans un mail doit pouvoir se faire une ligne cron je pense. Comme ça, ils reçoivent à intervalle bien régulier l’état réel de leur machine.

    Si tu utilises Thruk, il me semble que les dernières versions sont capables de générer des rapports PDF par mail programmables, ça peut aussi être intéressant, comme ça, ils reçoivent non seulement l’état, mais aussi l’historique sur une période donnée.

  • # obsess over host/ obsess over service

    Posté par  . Évalué à 1.

    Bonjour,

    Je pense que tu peux t'en sortir avec les commandes Obsess Over Service / Obsess Over Host.
    Ces fonctions permettent de lancer une commande après chaque check, peu importe l'état (hard/soft) et le résultat.

    Pour un service :

    obsess_over_services=1
    oscp_command=ma_commande1

    Pour un hôte :

    obsess_over_hosts=1
    ochp_command=ma_commande2

    Ainsi, il te suffirait d'écrire un script qui envoie un mail ou non en fonction de l'état de l'hôte/du service et du dernier mail envoyé (stocké dans un fichier temporaire). Dans la définition de la commande tu pourras donner en paramètre à ton script script les MACCROS dont tu auras besoin ($SERVICESTATE$, $HOSTNAME$, …)

    Je suis conscient que ce n'est pas la fonction première de ce genre de trucs, et que ça fait un peut bricolage, mais je pense que c'est le moyen le moins "sale" qui te permette d'arriver à tes fins.

    Bon après, je ne m'y connais pas énormément et je n'ai jamais utilisé ces fonctions donc c'est juste une idée…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.