Nagios 3.0

Posté par  (site web personnel) . Modéré par Bruno Michel.
Étiquettes :
0
18
mar.
2008
Technologie
Une longue année de développement, cinq versions alpha, sept versions bêta, trois versions release candidate, voilà résumé en quelques mots le chemin parcouru par le moteur Nagios depuis la version 2.0 sortie en février 2006 jusqu'à la version 3.0 sortie le 13 mars 2008.

Le projet Nagios est un moniteur de supervision, successeur de NetSaint. Il permet une supervision de serveurs, équipements réseaux et des services.

Le principe de Nagios est simple :
  • Un ordonnanceur gérant les actions ;
  • Une IHM légère via une interface web ;
  • Les sondes qui sont chargées d'effectuer les vérifications.

Nagios est sous licence GPL v2.

Bonne supervision de vos serveurs et services ! Le projet Nagios est composé des éléments distinctifs suivants :
  • Le moteur Nagios, qui passe en version 3.0, c'est le cœur de la solution, l'ordonnanceur ;
  • Les greffons Nagios, en version 1.4.11, ce sont les sondes exécutées par l'ordonnanceur ;
  • Des add-ons, environ 200 extensions disponibles.

Seuls les deux premiers éléments sont indispensables si vous voulez mettre en œuvre une solution basée sur Nagios.

Aller plus loin

  • # Déploiement

    Posté par  . Évalué à 7.

    Cette excellente solution libre est en cours de déploiement dans tout le réseau CNAMTS. Autrement dit, votre «sécu» est surveillée par Nagios. Gare à elle ;-)

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Déploiement

      Posté par  . Évalué à 4.

      Marrant, il y a trois ans, je faisais un stage au ministère de la santé, et les informaticiens connaissaient absolument pas Nagios. Même pas de nom.

      Ensuite bon, le ministère de la santé était pas du tout à l'époque un ministère qui préconisait le libre, ils ont été forcé d'installer deux serveurs de tests sous Redhat, mais rien de plus.
      • [^] # Re: Déploiement

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

        De nos jours, du MINEFI au MINDEF, en passant par le MEDAD (ex-Ministère de l'Équipement), je peux t'assurer qu'ils connaissent tous Nagios et de nombreux logiciels libres aussi. D'ailleurs, bien souvent, ils demandent à avoir du Nagios.
  • # Beau produit :)

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

    Utilisateur historique de netsaint, à l'époque pour Lautre Net (une assoce d'hébergement) puis de Nagios 1, puis 2, et maintenant 3 :), je l'utilise aussi pour ma boite (hosting aussi) : moralité, c'est non seulement un excellent produit, mais qui respecte très bien la philosophie unix : ne faire qu'une chose, mais la faire bien.

    Je conseille Nagios à tous ceux qui doivent superviser des machines serveurs ou stations.
    • [^] # Re: Beau produit :)

      Posté par  . Évalué à 1.

      Bonjour Benjamin,

      Je viens tout juste de m'inscrire sur ce forum en quête d'informations sur un produit que vous semblez particulièrement bien connaître, j'ai nommé "Nagios".

      Pour ma part, je débute sous Linux et n'ai jamais utilisé Nagios !
      J'ai donc tout naturellement quelques questions à poser à la communauté, si tant est que vous souhaitiez/puissiez y répondre.

      En fait, Nagios fait partie d'un projet que je dois mener à bien dans le cadre de ma soutenance à un stage en entreprise. Mes neurones ne sont plus très jeunes et j'ai besoin des conseils avisés des spécialistes du sujet...

      Sans plus attendre, voici quelques-unes de mes interrogations:
      - Est-ce qu'un newbee peut se débrouiller d'un tel projet en ayant lu la documentation au préalable?
      - Quels sont les points délicats/bloquants de Nagios, histoire de ne pas perdre trop de temps?
      - Quels sont les avantages de Nagios en termes économiques ?
      - Quels sont les + indéniables pour un Système d'Information à posséder cette solution?
      - Son exploitation mobilise-t'elle une personne?
      - Les alertes sont-elles facilement remontées par SMS ?
      - Faut-il nécessairement installer un client sur tous les postes à superviser ?
      - Etc.

      En vous remerciant par avance pour les éventuels éléments de réponse de vous voudrez bien m'apporter.

      Bien cordialement

      Eric
  • # IHM

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

    Au niveau de l'IHM de l'excellent Nagios il y a aussi Centreon :
    - http://www.centreon.com

    Quelques captures d'écran :
    - http://www.centreon.com/Product/Screenshots.html
    • [^] # Re: IHM

      Posté par  . Évalué à 7.

      Rarement vu quelque chose d'aussi mal codé que ce machin.

      Des bugs très très génants (perte de données de performance par exemple), des bugs d'interfaces, des bugs dans la gestion des process nagios.

      Bref, on est très très loin de la qualité de Nagios.

      Sans parler du script d'installation, une véritable boucherie, avec des choix pour le moins discutable.

      Je conseillerai plutot de regarder Lilac, pour la configuration, et PNP (PNP is Not Perfparse) pour la gestion des données de performances.

      Sinon, le projet Vigilo http://www.projet-vigilo.org/site/ semble très prometeur.
      • [^] # Re: IHM

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

        Dans la famille "autre projet similaire" :

        Il pourrait aussi y avoir bientôt BIP vu que les dev et le client sont ok pour le libérer (reste à convaincre les patrons des dev ... qui devraient se laisser convaincre par le client :p ). Certes, BIP ne dispose pas de plugin vrml... mais BIP surveille déjà plus de 20 000 unix (hp-ux solaris linux) en europe. Et sa v2 prends en charge windows... donc sera déployée sur 200 000 petits postes...
        Le MySQL derrière, faut qu' il tienne le choc ;)

        Blague à part, l' interface web est 'extremement' complexe de part la quantité de possibilites disponibles. Il faut compter 2 jours d' utilisation avant de commencer à entrevoir les possibilités! Et un plugin vmrl sera Extra :)

        Esperons que ce projet sera effectivement libéré. Deux raisons essentielles : il me semble que la solidité et l' efficacité de BIP intéresseront de très nombreuses personnes (physiques et morales). Et d' un autre côté il est probable que des contributions puissent être possibles, pour l' ihm web par exemple. (je ne sais pas si des contrib externes seraient acceptées, mais bon, on peut réver...)

        Libérez BIP, libérez BIP ! :)

        ps : BIP est une censure, en attendant que son petit nom puisse être donné lors de sa libération.
        ps 2 : le principal dev. de BIP est aussi actuellement le dev. de compbench : un benchmark de compilation de certains logiciels pour gcc. http://compbench.sf.net
        • [^] # Re: IHM

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

          À défaut d'avoir le nom du soft et le nom des boîtes impliquées, passe bien le mot à toutes les personnes impliquées qu'effectivement le grand public libriste aimerait voir sa libération le plus tôt possible.
      • [^] # Re: IHM

        Posté par  . Évalué à 4.

        Centreon a subit de nombreuses améliorations faisant suite aux retours des utilisateurs, et est a ce jour facile a prendre en main pour n'importe quel développeur qui souhaiterait y rajouter des fonctionnalités.

        Je peux citer a ce titre le moteur de template Smarty, quelques libraires PEAR assez pratiques (Quickform, DB...) ou encore RRDTool.

        Il existe il est vrai quelques failles de sécu, mais des contributeurs bienveillants les remontent et nous donnent les pistes pour les corriger.

        Le script d'installation est un reliquat de la version 0.01 de Centreon et a été repris de 0 pour la prochaine version 2.

        Donc mis à part le dernier point, je te trouve vraiment dur avec le produit, et tes critiques largement injustifiées, surtout que l'équipe travaille dur sur la prochaine version 2.

        Quand à Vigilo, deux choses, soit c'est un coming out qui explique ton post, soit tu ne l'as pas encore eu entre les mains ;-)
        • [^] # Re: IHM

          Posté par  . Évalué à 2.

          Pas hyper actif en tout cas...

          https://sourceforge.net/project/stats/detail.php?group_id=21(...)

          Mais les problèmes sur centreon, remontez les !! Y a un bugtracker... La on travaille sur le .deb, le RPM etc etc. Et pour la version 2, comme le dis rom, l'install a été pas mal modifié... Fini tout les scripts auto..
          • [^] # Re: IHM

            Posté par  . Évalué à 1.

            Ta mesure de l'activité du projet via le dépot public est une fumisterie.
            Ce projet est développé par C-S, en interne, et, peu à peu, il passe en en libre. Le dépot sf ne sert visiblement qu'a publier les sources rendues libre.

            Pour mesurer l'activité autour de ce projet, il va falloir attendre un peu et voir si les promesses sont tenues :
            http://www.projet-vigilo.org/site/feuille_de_route

            Pour les changements sur Centreon, j'attends d'avoir du temps libre pour y regarder et donner mon avis.
        • [^] # Re: IHM

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

          Petit retour d'utilisation de centreon dans ma société : c'est plutôt contrasté. Le positif : l'interface de configuration, les beaux graphiques.
          Le négatif : les vues de monitoring ne sont pas utilisables sur de gros réseaux avec beaucoup d'equipements (pas de notion de unhandled problems, pas de tactical overview).
          Bref notre NOC est revenu a l interface de nagios pour tous ce qui est monitoring. La configuration se fait toujours via centreon. (mais pour moi c'est encore plus simple avec des scripts et des flats file .csv).

          J'attends avec impatience la version 2.0 qui se basera enfin sur NDO.

          Pour les commentaires sur le code : je trouve ca sévere, c'est pas trop mal codé, c'est fait en smarty et l'organisation est pas vue (les topology par exemple). Le modele de la base de données est compréhensible; et c'est déjà grand.

          Donc pour moi c'est un bon projet , mais trop axé sur les outils de reporting, graphs, maps et qui a oublié que l'essentiel pour un outil de monitoring c'est d'avoir des vues claires pour les exploitants.
      • [^] # Re: IHM

        Posté par  . Évalué à 3.

        Je deploie et administre centreon depuis l'été dernier et je n'en suis finalement pas mécontent.

        Pour la petite histoire, la première fois que centreon est arrivé dans la boite qui m'emploie, c'était un stagiaire qui l'avait installé et face aux enormité du script d'install je lui avait dit d'arrêter le massacre :)

        Quand je m'y suis remis quelques mois plus tard, l'install était toujours aussi merdique mais elle ne se fait qu'une fois. Et non seulement l'install est pas top, mais les maj non plus. :/

        Sinon pour les bons côtés de la chose, c'est pour moi l'interface (même si elle est loin d'être parfaite) la plus sexy, et la plus pratique de nagios. et c'est bien tout ce qu'on demande à une interface. J'apprécie particulierement le fait qu'on puisse administrer nagios (création d'host, de services, etc ...), utilisé nagios (visualisation des alertes) et exploiter les données de perf avec le même logiciel.

        Je pense que le projet dans sa version 1.X n'était pas suffisemment aboutis et pas vraiment destiné à la grosse production (beaucoup de bug sus-cité très genant) et j'attend donc beaucoup de la 2.0 qui m'a l'air bien plus lissé et ouverte aux grosse prod ou aux nombreux environnements.

        J'éspère que la migration vers la 2.0 se fera en douceur et que tout se stabilisera vite.

        Bref, vivement la v2 et longue vie à centreon!
    • [^] # Re: IHM

      Posté par  . Évalué à 5.

      J'ai justement essayer d'installer Centreon hier...

      J'avoue que je me suis fait peur avec le nombre de dépendances et même pas un RPM à se mettre sous la dent.
      Et le pire, c'est que ma Suzette SLES 10.1 ne possède pas certains packages qu'il faut donc installer à la main (arg) .
      Il aurait ensuite fallu que je launche un infâme ./install.sh (arg²) sur un serveur de production (aaarrg). J'y ai d'ailleurs entrevu des stop apache/mysql à la barbare et autres joyeusetés donc j'ai même pas essayé!

      J'avais déjà galeré à configurer les fichiers de config Nagios sur mon pauvre parc de 20 serveurs.
      Trucs et Astuces : créer à la voler vos config nagios à partir de fichiers CSV ou similaires, vous perdrez du temps en codage Perl, mais au final, vous gagnerez en maintenance!! Ceux qui ont déjà vu un fichier de config Nagios me comprendront !

      J'ai beaucoup de respect pour les logiciels libres, et ce projet est légitime par le simple fait d'exister. Et j'ose à peine critiquer, car je sais que je pourrais à la rigueur m'impliquer dans l'amélioration de ces points...
      Mais la, c'en était trop...
      • [^] # Re: IHM

        Posté par  . Évalué à 5.

        J'ai oublier de tempérer mon post précédent en disant que, une fois bien configuré, Nagios fonctionne parfaitement et nous a sauvé la mise plus d'une fois!!! (et même si l'interface Web est vraiment fouilli et qu'il n'y a finalement qu'une seule page utile (non non, ce n'est pas la vue 3D qui marche qu'avec le plugin VRML....))

        Non sérieusement, je me moque, mais je pourrais pas m'en passer.
  • # Ah! Nagios....

    Posté par  . Évalué à 9.

    Le code de Nagios, tout un poème...



    *** common/objects.c:
    add_host[627]
    host *add_host(char *name, char *display_name, char *alias, char *address, char *check_period, int initial_state, double check_interval, double retry_interval, int max_attempts, int notify_up, int notify_down, int notify_unreachable, int notify_flapping, int notify_downtime, double notification_interval, double first_notification_delay, char *notification_period, int notifications_enabled, char *check_command, int checks_enabled, int accept_passive_checks, char *event_handler, int event_handler_enabled, int flap_detection_enabled, double low_flap_threshold, double high_flap_threshold, int flap_detection_on_up, int flap_detection_on_down, int flap_detection_on_unreachable, int stalk_on_up, int stalk_on_down, int stalk_on_unreachable, int process_perfdata, int failure_prediction_enabled, char *failure_prediction_options, int check_freshness, int freshness_threshold, char *notes, char *notes_url, char *action_url, char *icon_image, char *icon_image_alt, char *vrml_image, char *statusmap_image, int x_2d, int y_2d, int have_2d_coords, double x_3d, double y_3d, double z_3d, int have_3d_coords, int should_be_drawn, int retain_status_information, int retain_nonstatus_information, int obsess_over_host){

    *** xdata/xodtemplate.c:
    xodtemplate_register_host[10368]
    new_host=add_host(this_host->host_name, this_host->display_name, this_host->alias, (this_host->address==NULL)?this_host->host_name:this_host->address, this_host->check_period, this_host->initial_state, this_host->check_interval, this_host->retry_interval, this_host->max_check_attempts, this_host->notify_on_recovery, this_host->notify_on_down, this_host->notify_on_unreachable, this_host->notify_on_flapping, this_host->notify_on_downtime, this_host->notification_interval, this_host->first_notification_delay, this_host->notification_period, this_host->notifications_enabled, this_host->check_command, this_host->active_checks_enabled, this_host->passive_checks_enabled, this_host->event_handler, this_host->event_handler_enabled, this_host->flap_detection_enabled, this_host->low_flap_threshold, this_host->high_flap_threshold, this_host->flap_detection_on_up, this_host->flap_detection_on_down, this_host->flap_detection_on_unreachable, this_host->stalk_on_up, this_host->stalk_on_down, this_host->stalk_on_unreachable, this_host->process_perf_data, this_host->failure_prediction_enabled, this_host->failure_prediction_options, this_host->check_freshness, this_host->freshness_threshold, this_host->notes, this_host->notes_url, this_host->action_url, this_host->icon_image, this_host->icon_image_alt, this_host->vrml_image, this_host->statusmap_image, this_host->x_2d, this_host->y_2d, this_host->have_2d_coords, this_host->x_3d, this_host->y_3d, this_host->z_3d, this_host->have_3d_coords, TRUE, this_host->retain_status_information, this_host->retain_nonstatus_information, this_host->obsess_over_host);
    • [^] # Re: Ah! Nagios....

      Posté par  . Évalué à -1.

      Euh c'est du code généré automatiquement ou il y a des programmeurs assez **** pour developper comme ça?

      Je ne devrais pas poser la question vu le code pourri que j'ai déjà vu (dans un autre style), mais l'espoir fait vivre..
    • [^] # Re: Ah! Nagios....

      Posté par  . Évalué à 0.

      OMG.
      Enfin bon, c'est pas comme si c'était le seul projet à avoir un code immonde... :-(
      • [^] # Re: Ah! Nagios....

        Posté par  . Évalué à 6.

        Je ne parles pas trop en connaissance de cause pour Nagios mais je ne sais pas si 2 lignes spécialement choisies doivent automatiquement mener a la conclusion "tout le code est immonde"... Je suis sûr qu'on pourrait faire ça avec beaucoup de programmes :)
    • [^] # Re: Ah! Nagios....

      Posté par  . Évalué à 6.

      <bourin>
      wahoo,
      Tu as choisi la définition de la plus grosse fonction et un appel à cette dernière.
      Visiblement, un noeud, pour Nagios, à beaucoup de propriété, ce qui en soit n'est pas gênant au contraire : Cela veux dire que Nagios est très flexible...
      Dis moi, que préfères-tu ?
      - 1 appel à une fonction gros comme ca,
      ou
      - 55 appels à des fonctions différentes, sans avoir de garanti que in fine le noeud sera correct :
      new_host=create_host(this_host->host_name);
      set_display_name(new_host, this_host->display_name);
      set_alias(new_host, this_host->alias);
      ....

      Sachant que chacun de ces appels de fonctions entraine un contexte switch, cad des cycles de pénalités (j'ai plus le chiffres en tete, mais beaucoup).
      </bourin>

      Honnêtement, un outil de monitoring dois générer le minimum d'over-head possible. Donc il faut que sont code soit relativement optimisé. De fait, je trouve ces lignes plutôt intéressantes.

      Dis moi, sur la prochaine dépêche parlant de xorg, vas-tu nous parler de la fonction (à peine utilisé) XCreateSimpleWindow, qui contrairement à son nom à globalement le même nombres de paramètres à ceci près c'est que ce ne sont pas des int et autre char * mais plutot des XRect, XDisplay etc qui sont déjà crée par l'appel de fonction pas simple non-plus.

      Bref,
      bien à toi
      Sébastien
      • [^] # Re: Ah! Nagios....

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        Dans l'exemple donné par Barnabé, on a surtout envie de virer la liste d'arguments par la structure décrivant l'hôte...

        Ce qui est plus lisible, plus simple à utiliser.
      • [^] # Re: Ah! Nagios....

        Posté par  . Évalué à 10.

        Mon exemple est il est vrai caricatural, cependant, j'ai eu à travailler sur le code de Nagios, et c'est un bien mauvais souvenir. On sent bien le développement itératif, où l'ajout d'une fonctionnalité donne un membre supplémentaire dans la structure host, un dans service, quelques case en plus dans plein de switch, le tout avec peu de vue d'ensemble. C'est un code ardu à aborder, pénible à déboguer, avec des fonctions interminables dans des fichiers énormes.

        Pour l'exemple de la fonction add_host, je ne suis vraiment pas certain que de déposer 55 objets sur la pile soit plus optimal que de simplement passer le pointeur sur la structure déjà remplie.
      • [^] # Re: Ah! Nagios....

        Posté par  . Évalué à 3.

        C'est aussi la mise en forme du code qui est très très pénible à lire... Ca joue aussi.
      • [^] # Re: Ah! Nagios....

        Posté par  . Évalué à 3.

        > Sachant que chacun de ces appels de fonctions entraine un contexte switch, cad des cycles de pénalités (j'ai plus le chiffres en tete, mais beaucoup).


        Prends garde à pas tout mélanger non plus. Un appel de fonction, c'est effectivement quelques opérations :

        1) 'push' des parametres et du pointeur de retour sur la pile d'appel
        2) 'jump' vers le code de la fonction
        3) 'pop' des parametres
        4) execution du code de la fonction
        5) 'jump' vers le pointeur de retour

        Mais rien de monstrueux sauf, quand c'est une fonction très courte appelée très souvent auquel cas l'overhead est grand et on peut utiliser l'inlining (copie du code de la fonction).

        Rien a voir avec un 'context-switch', qui est une opération effectuée par le noyau et qui consiste en sauver le contexte d'exécution quelque part (registres, pointeur d'instruction courant etc...) et de le remplacer par un autre. Ce qui arrive dans 2 cas (en gros) :
        - changement de tache par l'ordonnanceur
        - appel système (passage du mode utilisateur au mode noyau)

        Et un context switch est effectivement très gourmand, par rapport a un appel de fonction en tout cas ;-).

        Comme le dis très justement quelqu'un plus bas, passer 270000 paramètres sur la ligne de commande ce n'est pas "optimisé", loin de là (par rapport a ce qu'on a vu plus haut, ca fait 270000 push et pop) par rapport a un passage sur la pile d'un ptr vers une structure pré-remplie.
    • [^] # Re: Ah! Nagios....

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

      On peut polémiquer sur la forme du code de Nagios mais en ce qui concerne l'efficacité et la stabilité du projet, rien à redire.
      On ne peut pas en dire autant de tous les projets dont la forme laisse à désirer (et puis bon, si tu voyais le code de la majorité des plugins de Nagios, tu partirais en courant).
    • [^] # Tournure d'esprit

      Posté par  . Évalué à 4.

      Il est vrai qu'à première vue, tous ces arguments pourraient être remplacés par un seul pointeur vers une structure.

      Nagios est peut-être programmé par des admins. Et les admins ont peut-être une tournure d'esprit qui ne correspond pas aux canons des "vrais" programmeurs.

      Ou pas :-)
  • # NagVis

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

    J'utilise Nagios depuis la 1.x et je dois dire que la plupart de mes serveurs de production sont encore bases sur la 1.x pour le moment.

    Pour ceux qui veulent du beau pour montrer a leur boss, il y a un beau frontend nomme : NagVis (http://www.nagvis.org/)
    • [^] # Re: NagVis

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

      À partir de Nagios 2, tu peux tirer parti de NDO avec NagVis et notamment disposer d'informations supplémentaires, comme les ACK.
  • # Migration de la version 2 vers la version 3

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

    Je viens de rédiger un tuto pour migrer facilement de la version 2 à la version 3 de Nagios.

    http://blog.nicolargo.com/2008/03/migration-facile-de-nagios(...)

    A+
  • # Plugin Nagios pour Cacti

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

    Pour ceux qui utilisent Nagios et Cacti, ce plugin est très prometteur : http://forums.cacti.net/about25902.html

    * Nagios data is handled via ndo2db (written/maintained by Nagios team)
    * A customizable dashboard view with various portlets to choose from
    * Tabbed interface (EXT) with asynchronous data loads
    * Must be a complete Nagios UI replacement (reports, maps, etc.)
    * Must import (graph) Nagios performance data (semi-auto)
    * Ability to link existing Cact service/host graphs to Nagios service/host
    * Host and service level permissions configured similar to Cacti
    • [^] # Re: Plugin Nagios pour Cacti

      Posté par  . Évalué à 5.

      Merci Frédéric, déjà pour ta présence appréciable sur les forums Cacti.

      Pour ce qui est du plugin NPC, je suis content de voir que l'auteur est revenu mais la dernière fois il avait déjà montré un début pas mal puis plus aucune information et le code disparu, plus moyen d'essayer de continuer. J'espère qu'il va pas nous refaire le coup, là on est quasiment à 1 mois sans nouvelles.

      C'est clair qu'il y a un gros besoin d'une interface un peu plus clean à Nagios, suffit de voir le nombre de projets qui s'y attelent, de Centreon (qui vraiment horrible) à GroundWork en passant par Vigileo ou même NaReTo. Je crois que le drame c'est que Nagios et ses plugins soient devenus tellement incontournables que tout le monde essaye d'en gaumer les défauts (la configuration, la visualisation) au lieu de repartir de quelque chose de clean.

      Pour avoir beaucoup travailler dessus, je pense qu'à moyen-terme, Cacti, une fois la Plug In Architecture intégrée nativement, sera une super base pour se recréer un système de supervision clean et efficace.
      • [^] # Re: Plugin Nagios pour Cacti

        Posté par  . Évalué à 5.

        >Pour avoir beaucoup travailler dessus, je pense qu'à moyen-terme, Cacti, une fois la Plug In Architecture intégrée nativement, sera une super base pour se recréer un système de supervision clean et efficace.

        Pour développer au quotidien autour de Cacti, je ne suis pas sûr que Cacti soit une si bonne base que ça pour faire un "système de supervision clean et efficace". En tous cas, pas plus que Nagios :

        * Le schéma de BDD est horrible (énormément de redondance d'infos, "templates" et données créées à partir de ces mêmes templates dans la même table).

        * Le code PHP est quand même bien crade : en plus d'être "oldschool" (ex: pas de PHP5), beaucoup de fonctions énormes, etc..

        Donc y a encore du boulot.

        LE point fort de Cacti sont ses templates : l'idée de base est excellente. Par contre, l'implémentation laisse vraiment à désirer :/
        • [^] # Re: Plugin Nagios pour Cacti

          Posté par  . Évalué à 4.

          Sur la partie où j'ai touché au code c'était surtout la PIA et je l'ai pas trouvé si horrible que ça. Mais c'est probablement parce que je suis pas spécialement habitué à coder en PHP donc pour moi ça suffisait amplement.

          Par contre c'est clair que le gros point noir dans Cacti c'est le schéma SQL qui est vraiment dégueulasse. Je me suis rendu compte quand je voulais voir si on pouvait pas mettre en place un cleanup lorsqu'on avait fini de jouer/tester un plugin (qui ajoute encore des tables et pas toujours de façon très propre) et déjà que j'étais pas fan de SQL à la base, ça m'a un peu coupé l'envie.

          Par contre à l'utilisation, templates + plugins, ça poutre tous les autres outils que j'ai pu essayer.
        • [^] # Re: Plugin Nagios pour Cacti

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

          LE point fort de Cacti sont ses templates : l'idée de base est excellente. Par contre, l'implémentation laisse vraiment à désirer :/

          Peux-tu développer ? Sous Nagios, il y a également des templates.
          Je présume que tu voulais parler des templates pour les graphiques, non ?
          Je pense qu'il est prématuré de jeter dos-à-dos Cacti et Nagios car les deux projets ont des similarités mais poursuivent des buts bien différents et se retrouvent assez complémentaires.
          Pour autant, je regrette que le réseau soit surchargé par des requêtes redondantes par l'emploi simultané de Cacti et Nagios.
      • [^] # Re: Plugin Nagios pour Cacti

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

        Pour avoir beaucoup travailler dessus, je pense qu'à moyen-terme, Cacti, une fois la Plug In Architecture intégrée nativement, sera une super base pour se recréer un système de supervision clean et efficace.

        L'architecture plugin (PIA) est intégreé dans le SVN de la version 0.8.8 :-)
  • # Hobbit ?

    Posté par  . Évalué à 2.

    Je suis surpris que personne ne parle de ce fork de bigbrother. J'ai plusieur fois tenté d'installer nagios ... sans succés. Je trouve ca horriblement compliqué pour mon petit cerveau :(.

    Alors que hobbit est d'une simplicité déconcertante et d'une souplesse très agréable. Ok le résultat est pas super sexy mais il est très très efficace.

    En tout cas je l'utilise et je pousse ma boite à l'utiliser. En remplacement de cette horreur de SRM dans un premier temps et peut être de tivoli/patrol un jour. En tout cas dans ma boite précédente c'est ce qui a été fait. Remplacer patrol,netview,what'up et un truc pour vérifier des urls par hobbit.
    • [^] # Re: Hobbit ?

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

      J'allais justement parler de Hobbit ;-)

      Chez nous il supervise ~ 4.500 équipements (~ 25.000 points de supervision, la plupart étant l'équivalent des "passive checks" de Nagios avec des clients Hobbit installés sur les machines Unix/Windows).

      Pour moi ses gros avantages sont sa rapidité de mise en place, sa fiabilité, sa capacité à monter en charge (via l'ajout de serveurs Hobbit pour les tests réseau, de proxies pour les "passive checks") et sa compatibilité avec les scripts Big Brother.
      Des "plugins", comme Devmon, pour une supervision SNMP assez pousée basée sur des templates, ainsi que BBwin, client Hobbit pour Windows développé par un français, le rendent encore plus efficace.

      Par contre, le fait que l'unique développeur de la partie Unix de Hobbit soit (AMHA) assez fermé, sorte des patches pas vraiment référencés et n'ait pas sorti de version stable depuis 18 mois font que si c'était à refaire, je pencherais peut-être vers Nagios...

      Pour ceux qui utilisent Hobbit, la version 4.3 va proposer la détection de "bagotements" (flapping), la gestion des jours fériés/vacances (pour les règles d'alarme), une gestion native de SNMP, des stats sur les machines ayant le plus de changements d'états, etc.
      • [^] # Re: Hobbit ?

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

        Effectivement j'ai également utilisé Hobbit sur un parc de 300 machines tous Unix confondus (HP-UX, Linux, Solaris, AIX), dont des clusters sur SuperDome et il a niqué grave HP OpenView en place depuis longtemps, en le remplaçant avantageusement en terme de réactivité, simplicité, rapidité, montée en charge. Il a tout simplement séduit toute la DSI en quelques semaines à quelques mois.
        • [^] # HP Overload

          Posté par  . Évalué à 3.

          En même temps, pas bien difficile de "niquer grave" HP OpenView hein :-)

Suivre le flux des commentaires

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