Announcement

Collapse
No announcement yet.

Petit sondage sur les manques de Nagios

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Petit sondage sur les manques de Nagios

    Bonjour tout le monde,

    J'aimerai bien avoir votre avis sur ce qui représente pour vous les plus gros manques de Nagios, que ce soit en terme de perf, d'architecture ou autre.

    Pour la part je vote pour les performances à améliorer, des environnements distribués qui se gèrent tous seuls, sans avoir à répartir à la main ses machines et enfin des notifications unifiées et non réparties.

    Vos avis?
    Auteur de Shinken, outil de supervision compatible avec Nagios et orientée supervision distribuée hautement disponible et mulitplateforme.

  • #2
    J'ajouterais la gestion de la parenté des hosts entre poller Nagios.
    Centreon Syslog Module Manager/Developper
    Centreon E2S Module Manager/Developper
    Centreon Enterprise Server (2.x / 3.x) : Centreon Engine 1.3.x / 1.4.x, Centreon Broker 2.6.x / 2.8.x , Centreon 2.x, Centreon-Syslog 1.5.x, Centreon E2S 2.0
    Nagios 3.x et NDOutil 1.x

    Comment


    • #3
      Très judicieux en effet.
      Auteur de Shinken, outil de supervision compatible avec Nagios et orientée supervision distribuée hautement disponible et mulitplateforme.

      Comment


      • #4
        Hum j'ajouterais aussi la gestion correcte du changement d'heure été/hiver et surement hiver/été qui a fait planter plus d'un Nagios ce week-end.
        Centreon Syslog Module Manager/Developper
        Centreon E2S Module Manager/Developper
        Centreon Enterprise Server (2.x / 3.x) : Centreon Engine 1.3.x / 1.4.x, Centreon Broker 2.6.x / 2.8.x , Centreon 2.x, Centreon-Syslog 1.5.x, Centreon E2S 2.0
        Nagios 3.x et NDOutil 1.x

        Comment


        • #5
          C'est space, Nagios est censé gérer cela en détectant un changement d'heure, et recheduler comme il faut ses checks.
          Auteur de Shinken, outil de supervision compatible avec Nagios et orientée supervision distribuée hautement disponible et mulitplateforme.

          Comment


          • #6
            Bonjour,

            J'ai un premier besoin, mais qui va probablement à l'encontre de l'architecture de Nagios qui est plutôt orientée "notifications". Je précise que de mon côté il est exclu de faire une supervision par réception d'emails ou autres SMS. C'est selon moi déresponsabilisant au possible d'envoyer des emails à toute une liste de contacts, sachant qu'il y a toujours le risque de passer à côté (du mail critique), ou tout simplement de se dire que c'est déjà pris en compte par quelqu'un d'autre. Donc pour moi, la bonne interface de supervision, c'est une console avec des personnes derrière dont le métier est de suivre et traiter les alertes.

            Et donc après une évaluation de 3 mois de Nagios + Centreon, j'ai compris qu'il n'y avait pas de console événementielle de supervision, ni dans l'un, ni dans l'autre.
            En effet, les pages de monitoring, selon le filtrage effectué, montrent une photo à l'instant "t" de l'état d'un certain nombre de services et/ou de hosts. Or, si un service est à l'état OK à 8h05, KO à 8h10 et à nouveau OK à 8h15, et que l'équipe de pilotage ne l'a pas vu (je précise qu'il n'y a pas de notifications activées), il y a un risque de passer à côté de cette alerte. Bien entendu, cette alerte sera visible dans l'historique, mais dans ce cas on ne travaille plus en temps réel.
            L'idéal serait donc d'avoir une console de monitoring qui liste toutes les alertes au fur et à mesure qu'elles sont arrivées, et qui permettent les mêmes opérations que celles prévues dans les pages de monitoring (disable check, acknowledge...).


            Autres points :
            1) la dépendance de services, une fois configurée, peut limiter les notifications (et stopper les contrôles superflus), mais l'état des services dépendants peut tout de même être KO et donc être affiché tel quel sur les pages de monitoring (cf. post que j'ai commencé il y a quelques semaines à ce sujet : http://forum.centreon.com/f16/servic...dencies-t8920/).
            Encore une fois, c'est lié à l'architecture "notifications" de Nagios.
            Ce qui serait bien, c'est que l'état des services dépendants soit ignoré dès que le service maître respecte les critères configurés. Et donc que les services dépendants ne soient pas indiqués comme KO sur la console de monitoring.


            2) les groupes de hosts et de services sont utiles, mais lors de leur affichage sous les pages de monitoring, leur statut n'est pas consolidé.
            Exemple : je crée un groupe de services appelé "Applications critiques" et je lui affecte 4 services. Si l'un d'entre eux est KO, j'aimerais bien que le statut du groupe de services l'affiche (avec un code couleur et/ou un statut OK/KO...). J'ai constaté que NagVis est de son côté capable de consolider l'état d'un host (en prenant en compte l'état de ses services) ou l'état de groupes de hosts (ou services). Et c'est très pratique pour avoir une vision macroscopique (cf. post http://forum.centreon.com/f10/global...-groups-t8919/).

            Remarque : j'ai 4 versions de retard sur Centreon et sur Nagios, peut-être que ces besoins ont déjà été pris en compte dans les versions ultérieures, mais d'après les change logs que j'ai lus, je ne crois pas.

            Ben
            Ben
            FAN 2 beta 2 (Nagios® 3.0.6 - Centreon 2.0.2)
            4 hosts, 66 services (it's a try )

            Comment


            • #7
              Concernant la supervision macroscopique, ce n'est pas parque q'un service est KO sur 1000 que l'hôte est KO pour autant. La page http met plus de 7 secondes à répondra (critique si supérieur à 5s) mais ce n'est pas pour autant que le partage samba, la présence sur le réseau (réponse au PING) l'état des bases de données sont altérées.

              La supervision macroscopique est intéressante mais dans des cas bien précis et non générique.

              Il existe cependant des applications permettant de faire ceci comme vous l'avez cité: NagVip mais aussi d'autre tel Centreon-MAP.

              Centreon doit pouvoir répondre à un grand nombre de besoin de façon générique.

              Pour revenir au sujet des notifications, il est plus intéressant de notifier un groupe restreint qui aura vraiment la main et surtout la charge de corriger le problème. Il est tout aussi intéressant d'utiliser les escalades permettant ainsi une prise en compte gradué de la résolution des problèmes. Ces problématiques sont assez lourde à mettre en place (définition des groupes, des escalade) mais une fois intégrées elle permette de ne pas passer à coté d'un incident.

              Cependant un bac temps réel ou les alertes sont stockées est une idée intéressant mais plus pour le développement de Centreon.
              A proposer donc sur la forge de Centreon pour une évolution future (forge.centreon.com)
              Last edited by AkHeNaToN; 29th October 2009, 17:44.
              Centreon Syslog Module Manager/Developper
              Centreon E2S Module Manager/Developper
              Centreon Enterprise Server (2.x / 3.x) : Centreon Engine 1.3.x / 1.4.x, Centreon Broker 2.6.x / 2.8.x , Centreon 2.x, Centreon-Syslog 1.5.x, Centreon E2S 2.0
              Nagios 3.x et NDOutil 1.x

              Comment


              • #8
                Merci pour les remarques Ben. Je vois surtout que ce sont les notifications qui te gènes. Comme l'a répondu très justement AkHeNaToN regarde du côté des escalades pour ne rien perdre et alléger tes équipes de derniers niveaux.
                L'idée du pool d'alerte est pas mal. Il faudrait une sorte d'ouverture de tickets en gros.
                Auteur de Shinken, outil de supervision compatible avec Nagios et orientée supervision distribuée hautement disponible et mulitplateforme.

                Comment


                • #9
                  Bonjour,

                  J'ai les mêmes besoins que BenNag en ce qui concerne la vue 'évènementielle' des alertes. Dans mon cas, je suis en train de me servir du global_service_event_handler pour insérer des évènements dans une table MySQL. Mais c'est vrai qu'il manque un module permettant de voir les alertes passées.
                  Nagios 3.0.6
                  Centreon 2.1.8
                  RedHat 5.4

                  Comment

                  Working...
                  X