Nagios World Conference à Bolzano
Le 12 mai dernier, se déroula à Bolzano la Nagios World Conference. Des invités de marque, tels que Ethan Galstad lui-même, étaient présents, ainsi que l’équipe Somone. Somone vous propose un résumé des points marquants de cette conférence.
Rencontre avec Ethan Galstad et Andreas Ericsson
Nous discutâmes avec Ethan Galstad, le créateur et principal développeur de Nagios, et Andreas Ericsson, « core » développeur de Nagios.
Avancement du développement de Nagios
Après les présentations d’usage, nous les questionnâmes sur les inquiétudes qu’ont beaucoup de personnes concernant l’avancement de Nagios, qui semble être au point mort. Andreas s’empressa de nous donner tort, annonçant qu’une version 3.3 était imminente, testée depuis déjà longtemps par Op5 sur de grands environnements. Il souligna ensuite que les releases étaient publiées « when it’s done », les ressources de l’équipe de développement étant limitées. Ils insistèrent sur le manque de ressource de leur équipe de développement, Andreas par exemple ne pouvant travailler sur Nagios Core que une à deux heures le mercredi quand il a le temps.
Contributions externes
Concernant ce point, nous lui fîmes part des reproches de la communauté françaises, pour qui les tentatives de contribution sont injustement rejetées, citant les exemples de Jean Gabès et Merethis. Ethan et Andreas nous répondirent que les fonctionnalités rejetées l’étaient car elles n’étaient pas utiles pour tout le monde. Ils indiquèrent très clairement être totalement ouvert aux patchs, mais que les fonctionnalités apportées devaient être utiles pour le plus de monde possible et non seulement pour un produit en particulier, et de plus devaient rester dans l’esprit core de Nagios. En effet Andreas indiqua qu’il ne souhaitait pas que Nagios deviennent « bloated », et que de nombreuses fonctionnalités demandées avaient leur place à l’extérieur de Nagios, dans des brokers par exemple. Dans les fonctionnalités à ajouter nous évoquâmes la gestion des environnement distribués. Pour Andreas cette gestion doit se situer à l’extérieur de Nagios, dans un broker. Il cita l’exemple de Merlin, le broker utilisé par Op5, pour lequel il travaille. De plus les contributions doivent aussi rester compatibles avec l’existant.
Performances
À propos des brokers, Ethant trouve NDO suffisant, il l’utilise dans Nagios XI avec quelques patches en plus, pour le rendre non bloquant par exemple. Il a publié quelques-uns de ces patches, mais NDO n’est plus maintenu.
Nous évoquâmes ensuite les performances limitées de notre point de vue de Nagios core. Andreas répliqua en indiquant qu’il était parvenu à réaliser 600k checks en cinq minutes avec Nagios core. Ces tests étaient des tests bidons renvoyant toujours la même chose immédiatement. Cet exemple lui permit d’illustrer que la limite des performances de Nagios core ne se situe pas au niveau de l’ordonnancement, mais au niveau des plugins en eux-mêmes, et des éléments extérieurs au cœur comme les graphes de performances, très gourmands en entrées/sorties selon lui, et les différents modules.
Pour Ethan et Andreas, il est plus important de bien définir les besoins de la solution de supervision pour éliminer les éléments inutiles pouvant gréver les performances, que de se concentrer sur l’optimisation à tout prix du cœur de Nagios.
Forks de Nagios
Nous leur demandâmes également leur avis sur les différents forks de Nagios, Shinken, Icinga et Centreon Core en particulier. Concernant Shinken, ils trouvent l’idée intéressante, mais qu’il fait trop de choses selon eux. Icinga selon eux est un fork politique et non technique. Pour Centreon-Engine, ils trouvent également le projet intéressants, mais sont curieux de voir si leurs auteurs vont remonter leurs patchs vers Nagios.
Roadmap
Ils finirent la discussion en nous expliquant qu’une réunion des développeurs de Nagios allait se tenir le lendemain, et qu’ils allaient discuter des fonctionnalités à apporter à Nagios, afin de demander des contributions pour implémenter ces fonctionnalités. D’ailleurs quelques unes ont été publiées sur la liste de diffusion nagios-devel.
Présentation de Ethan Galstad sur Nagios
Le lendemain nous assistâmes à la présentation d’Ethan sur Nagios. Voici un résumé des points abordés.
Situation de Nagios
Nagios est très utilisé de part le monde, il recense un million d’utilisateurs. Nagios est donc très utilisé, prouvé, ancien, et a une grosse communauté. Ses possibilités de personnalisation sont très importantes et son prix est imbattable.
Développements récents
De nombreuses choses très intéressantes se firent ces vingt derniers mois. L’équipe des développeurs (« la core team ») fut agrandie. Un nouveau thème (« Exfoliation ») fut publié pour l’interface web de Nagios. Des améliorations de performances et des résolutions de bugs furent effectuées.
Nagios core est presque complet (« feature complete »), c’est un scheduler et il remplit presque parfaitement ce rôle. Certains projets sont trop bloated, ils incluent trop de fonctionnalités. Nagios core doit se concentrer sur son but premier.
Projets en cours
Des projets en cours de développement furent cités :
- V-Shell : nouvelle GUI PHP pour Nagios
- Nagios BPI : processus business
- NRPD : remplacement de NSCA, utilise HTTP pour communiquer. C’est un projet principalement développé par Ethan.
- Seedcamp : concours d’innovation, permet de collecter de nouvelles idées
- Programme de formation officiel
- Une nouvelle interface de configuration de Nagios, basée sur NagiosQL sera prête dans deux mois : Nagios CCM.
- Une machine virtuelle contenant un assemblage de briques open-source de supervision sera publiée : Nagios Montage. Cet assemblage contient :
Plugins BPI Exfoliation NRDP Nagios core NagiosQL/CCM Nagiosgraph NSCA Nagvis - Nsclient++ permettra de réaliser de nouveaux agents passifs pour Windows/*Nix.
Société Nagios
La societé Nagios propose du support pour les administrateurs et sur des projets de supervision.
Un programme de certification et de tests en ligne va être lancé.
Pour conclure
La conférence de Bolzano fut très rassurante sur l’avenir de Nagios. L’équipe de développement du core est ouverte aux contributions, mais est très stricte sur la pertinence de celles-ci. De nombreux projets autour de Nagios avancent : nouvelle interface en PHP, nouvelle interface de configuration, remplacement de NSCA utilisant des protocoles standards, nouveau NSClient++. De plus la société Nagios proposera des programme de certification et de formation.
Les développeurs de Nagios étudient avec attention les forks de Nagios et attendent des remontés de leur part. Une roadmap fut discutée et soumise à la communauté en demandant des contributions. Le cœur est presque complet, les évolutions plus importantes se font autour de lui.
9 Comments
Leave a Comment
Vous devez être connecté pour publier un commentaire.
Licence
Sauf mention spéciale, le contenu de ce site est distribué sous licence Creative Commons version BY 3.0.
« en indiquant qu’il était parvenu à réaliser 600k checks en cinq minutes avec Nagios core. » heu là va falloir qu’il nous explique alors : même avec des tests bidons, on monte à 10k/5min, et avec les tweaks 30K, pas plus (latence explosée sinon).
Le vrai soucis est bien dans l’ordonnanceur avec le reaping process qui parse du fichier plat, et là les 600k/5min c’est tout simplement infaisable…
Vu que vous avez réussi à lui parler, vous pouvez lui demander de poster ces résultats (et leurs conditions)? Merci 😀
Il en parle là : http://blogs.op5.org/blog4.php/2010/10/25/blocking-and-more-stress
Par contre il semble faire ça avec plusieurs Nagios, donc je ne sais pas s’il nous parlait vraiment de ça ou d’autre chose.
Eh là c’est un bench de l’echange entre Merlin et Nagios et non un bench sur les vitesse de lancement des sondes de Nagios on dirait, surtout avec le nombre de pollers qu’il a mis en face.
A voir donc. Mais ça revient à ce que propose Andreas sur la mailing list, de virer le reaper process par une communication socket. Mais ça reste à faire, même si l’idée date d’il y a deux ans maintenant.
Leur logique ne me choque pas, même si nagios est vu comme un ordonnanceur, il n’en reste pas moins un outil de supervision qui pour moi doit au moins répondre aux problématique de scalabilité et faciliter d’administration et d’utilisation.
Avec cette logique de dire que c’est un scheduleur est qu’il le fait très bien et que ça ne doit pas changer … C’est vulgariser Nagios et se fermer à l’évolution des S.I.
Pour la question de dev limité, ça ne reste pas moins leurs fautes à être très stricte sur l’entrer dans la core-team.
C’est un échange très intéressant et je suis d’accord qu’il ne faut pas tomber dans le piège de vouloir la cafetière senseo avec un seul outil.
Par contre pour les perf, je demande à voir 😉
Justement, ils le disent très clairement, Nagios n’est pas que Nagios Core. Nagios core a un objectif très précis (le scheduling) et toutes les fonctionnalités plus haut niveau (haute-dispo, environnement distribué, etc) doit se faire à un autre niveau, dans les brokers par exemple.
Pour eux, bloquer le cœur à certaines fonctionnalités, ce n’est pas pour les bloquer à Nagios, c’est pour ne pas les mettre au mauvais endroit.
Ouais je veux bien mais un outil où tu finis par avoir 36 broker, ça fait un peu usine à gaz aussi à la fin surtout à présenter ça à un DSI.
« Write programs that do one thing and do it well ».
Pourtant c’est à la mode les architectures modulaire.
Bonjour,
25K/5minutes avec ndo sur mon ordinateur portable (disque dur plus lent que la moyenne à première vue) ça ne pose pas problèmes.
Le tweak :
use_large_installation_tweaks=1
enable_environment_macros=0
Dans la configuration Nagios
Ajouter un index sur le champs object_id de nagios_services il me semble, dans la base ndo.
C’est tout à fait juste. Un ordonnanceur n’a que deux états : OK/pas OK pour les perfs. Maintenant tente de dépasser le seuil des 35K avec tous les tweaks et des fichiers plat sur ramdisk. Tu verras ta latence exploser tout de même.