Sortie de Nagios 3.4.0

Posté par  (site web personnel) . Édité par Florent Zara, Nils Ratusznik, baud123, claudex et NeoX. Modéré par j. Licence CC By‑SA.
Étiquettes :
27
10
mai
2012
Supervision

Après une gestation de 9 mois, Ethan Galstad a annoncé lundi dernier la publication d'une nouvelle version de Nagios Core, la 3.4.0. C'est une solution logicielle, sous licence GPL, de surveillance système et réseau. le cœur du système s'occupe d'ordonnancer les tâches de supervision.

Nouvelles fonctionnalités :

  • Utilisation de la fonction execv() pour les checks actifs (#86) ;
  • Nouvelle directive service_check_timeout_state ;
  • Réduction de la charge induite par les notifications en déplaçant la vérification des adresses viables avant l'alimentation de la liste de notification (PATCH) ;
  • Les utilisateurs peuvent à présent avoir accès aux groupes d'hôtes et de services contenant au moins un hôte ou service pour lesquels ils ont déjà l'autorisation (au lieu de devoir les autoriser à accéder à tous les groupes) ;
  • Réduction de la latence sur les gros environnements en évitant d'attendre inutilement (sleep) lorsqu'un évènement n'est pas planifié (initialement pour éviter de monopoliser le CPU) (PATCH).

Corrections :

  • Résolution du fonctionnement de la directive allow_empty_hostgroup_assignment, introduite avec la 3.2.3 (#210) ;
  • Résolution de la création de la macro $NOTIFICATIONRECIPIENTS$, évitant d'ajouter toutes les adresses de contacts si ces derniers sont exclus par les directives host_notification_options ou service_notification_options (#98) ;
  • Résolution du fonctionnement de la macro $NOTIFICATIONTYPE$ qui ne pouvait jamais être à « CUSTOM » malgré ce que prévoit la documentation (#168).

Dans le code

Initiée en 2010 par un patch de Matthieu Kermagoret (Méréthis), l'utilisation de la fonction execv() remplace désormais popen() et system() pour l'exécution des checks actifs. Le but est évidemment de réduire la charge induite par les multiples exécutions de greffons. (NdM : pour rappel, system() fait un appel au shell pour exécuter la commande, contrairement à execv(), ce dernier permet donc d'éviter de charger un processus inutilement) Cela n'est pas sans rappeler le travail de Matthias Kettner avec livecheck. Parti du même constat concernant l'exécution des greffons, ce dernier a développé cette extension de livestatus, intégrée depuis la version 1.1.13i1, permettant d'éviter l'utilisation coûteuse de fork(). Ce développement aurait sans doute pu être évité si le précédent patch avait été intégré plus tôt dans le cœur de Nagios. L'avenir nous dira laquelle des deux solutions sera pérenne.

Là encore, la nouvelle directive service_check_timeout_state est issue d'un patch fourni en 2010 par Bill McGonigle, déjà appliqué dans Icinga à partir de la version 1.0.1. Elle permet de résoudre certains problèmes liés à la latence du réseau. En effet, un service qui dépend d'un service réseau (SSH, NRPE, SNMP) qui n'est pas toujours disponible n'est pas nécessairement dans un état CRITICAL ou WARNING. On peut considérer qu'il est simplement dans un état UNKNOWN car réellement inconnu, faute de connexion.

Aller plus loin

  • # Erreur de compilation

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

    Attention : il semblerait qu'une omission dans le code empêche la bonne marche de la compilation.
    http://thread.gmane.org/gmane.network.nagios.user/73630

  • # Quelques fautes...

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

    C'est une solution logiciel

    C'est une solution logicielle

    la commenande

    la commande

    d'une service

    d'un service

  • # Shinken

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

    Salut!

    J'avais suivi avec pas mal d'intérêt la réécriture de Nagios en python, Shinken.
    Est-ce que des gens ont fait le switch depuis sa sortie en version 1.0?

    Si oui, est-ce qu'il y a des retours sur cette migration?

    J'avoue qu'à l'époque où j'avais parcouru les mailing lists où le mec annonçait sa réécriture, il semblait assez remonté contre le noyau dur des devs de Nagios, qui avaient jeté son idée sans même y montrer un quelque intérêt.
    Le développeur à l'origine de l'écriture de shinken annonçait des perfs monstrueuses sous Shinken, est-ce que ça s'est vérifié?
    Est-ce que Nagios a rattrapé ces perfs?

    • [^] # Re: Shinken

      Posté par  . Évalué à 5.

      Salut,

      J'ai remplacé sur la partie production de mon infrastructure ( 500 hôtes et plus de 5000 services ) Nagios 3.2 par Shinken 1.0.1 pour les problèmes de performance.

      L'avantage de Shinken c'est qu'il est plus facile a mettre en oeuvre dans une environnement distribué. Avec le même type de machine, j'ai moins de latence avec Shinken.

      De plus tu as des paquets RPMs et DEB.

      A+

      • [^] # Re: Shinken

        Posté par  . Évalué à 2.

        Justement, pour les .deb par exemple les derniers paquets disponibles dans debian sid sont pour la version 0.6.5, idem pour ubuntu. On ne trouve pas la version 1.0.x, même en ppa.

        C'est dommage, car c'est un frein à l'adoption AMA.
        L'installation par script, c'est bien pour tester sur une machine, mais pour la production il faut avoir une raison impérieuse pour ne pas passer par un paquet; à moins de tout installer en tant qu'utilisateur simple dans un seul répertoire, éventuellement.

    • [^] # Re: Shinken

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

      Salut,

      il semblait assez remonté contre le noyau dur des devs de Nagios

      Oh juste un peu ;)

      Il est désormais rigolo de voir que l'orientation de Nagios va vers ce qu'ils ont si bien refusés, à savoir réduire l'impact des lancements de sondes (execve est une partie de la solution, mais il reste encore le plus lourd à gérer)…

      Pour les performances pures (si on oublie les besoins genre environnements en DMZ, haute-dispo ou corrélation), une solution pour faire durer son nagios un peu plus longtemps est mod_gearman, de l'auteur de Thruk. C'est aussi performant que Shinken pour le lancement des sondes.

      Justement Shinken est vu comme "juste" un booster de performances (ce qu'il est mais pas que). La 1.0 avec son UI a mis en avant la partie "corrélation" des informations, et avec la prochaine ça va être la partie amélioration sur la partie configuration qui va être mise en avant (enfin on va essayer :) ) avec une UI de configuration.

      Concernant les références, pour l'instant il y a surtout des "gros", mais qui mettent bien du temps à autoriser les référencements (voir certains qui nous refusent catégoriquement, mais bon, c'est leur droit :) ). Il faut dire que je n'ai pas encore fait un appel aux références, faudrait déjà que je commence par ça…

  • # Shinken

    Posté par  . Évalué à 1.

    Ben, ça marche plutôt pas mal, assez bien même.
    Les fonctionnalités sont là et vraiment bluffantes.
    Quelques bugs mineurs et erreurs de jeunesse, une interface web native en cours de refonte.
    Utilisé avec Thruk ou multisite, c'est fonctionnel et efficace.
    Je recommande l'interface avec GLPI et Graphite.

  • # Rollback

    Posté par  . Évalué à 3.

    Rollback sur nagios 3.3.1

    http://www.nagios.org/news/77-news-announcements/307-new-core-release-shortly

  • # Sortie de la version 3.4.1

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

    Suite au retrait de la version 3.4.0 du site officiel, à cause d'un effet de bord (#332) apporté par execv avec les définitions de commandes utilisant des guillements, la version 3.4.1 corrigeant cette anomalie vient d'être publiée aujourd'hui :

    http://www.nagios.org/news/77-news-announcements/308-nagios-core-341-released

Suivre le flux des commentaires

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