Certains ont dû le remarquer : j'ai fait une proposition étonnante sur la mailing list de Nagios devel. Je ne propose rien de moins que de mettre Shinken comme branche développement de Nagios4 au lieu de l'ancienne implémentation C. Regardons un peu pourquoi je propose cela.

NOTE 2021: vous remarquerez là une méthode bien typique de la philosophie: tu balances une bombe H et tu es sûr de reveiller du monde :)

L'histoire récente de Nagios

Shinken est parti comme un proof of concept que j'utilisais pour démontre que mes idées pour Nagios n'étaient pas complètement absurdes. En effet, les patchs que j'ai proposés ont tous eu du mal à intégrer le core. Pourtant je les ait bien expliqué (enfin je crois), documenté et codé. Il est très simple de faire accepter un patch de correction dans Nagios, mais un patch d'amélioration de fonctionnement est bien plus long a intégrer. Pourquoi? Maitriser le cœur de Nagios n'est pas chose aisée, et je suis loin de connaître toutes ses subtilités malgré le temps que j'ai passé à le lire.

Jusqu'il y a quelques mois, Ethan était seul à accepter les patchs pour Nagios. Mes patchs ont étés magnifiquement ignorés à cette époque. Puis il y a eu l'histoire Icinga. Là Ethan a eu chaud, mais a bien réagit : il a ouvert l'accès au CVS à d'autres dev. Et hop, pleins de patchs on étés intégrés, dont les miens. Il y a eu aussi une ouverture de nagios ideas et cie. Très bien.

Et depuis? Bah Ethan se fait toujours aussi absent de la mailing list. Et qu'est ce qu'il nous sort? Nagios XI. C'est quoi cette bête? Et bien tout simplement une jolie couche graphique pour Nagios. Quel est l'intérêt face à des solutions comme Ninja ou même Centreon? Aucun. Un désavantage? C'est payant (quel bonheur de gérer des licences..) et non libre!!

Un Nagios a deux vitesses

On ne peux pas trop lui jeter la pierre, Ethan doit faire vivre sa société, et s'il décide de faire plus que du conseil/intégration et de vendre ses licenses on n'a pas à s'y opposer après tout, c'est son choix. Mais celui-ci implique que des parties des améliorations de Nagios ne seront plus open source. Il est prévu un module pour la supervision distribué... dans XI, pas dans le core. On voit poindre à l'horizon un Nagios a deux vitesses:

• Nagios community : le Nagios open source que l'on a sous la main
• Nagios Enterprise : le Nagios d'Ethan avec pleins de trucs géniaux, mais en close source et sous licence.

Bien d'autres font ça, Zenoss par exemple. Personnellement je ne suis pas un grand fan de ce modèle. Je n'aime pas gérer les licences, ça tombe toujours au mauvais moment ces trucs là. Je ne parle même pas de la communauté Nagios qui va fondre comme neige au soleil (vers Zabbix peut être?). Ce n'est pas acceptable.

Une stagnation dangereuse pour Nagios et une solution

Il faut un Nagios full open source qui évolue plus vite. Zenoss avance vite, Zabbix aussi, Nagios doit faire au moins aussi bien. Bien sûr il ne faut pas casser la compatibilité pour les users, c'est à dire la configuration. Mais le reste? L'administrateur s'en fiche bien que ce soit une implémentation ou une autre le temps que ça marche pareil (voir mieux...).

Les core dev ne sont pas fans des grands changement (purement technique) au sein du core. Leur réponse à un changement comme avoir un pool de process n'est pas " c'est totalement débile comme idée", mais "ça change trop de choses". On peut alors légitimement se poser la question sur l'avenir de Nagios. Si les propositions inovantes ne sont pas retenues, même si elles sont pertinentes, c'est qu'il y a un problème.

Quel est-il ce problème justement? A mon avis, il vient de l'implémentation actuelle en C. J'aime le C, mais pas pour tout. Quoique l'on peut penser, un scheduler n'est pas un travail de bas niveau. Alors pourquoi Nagios est en C? Car il a plus de 10ans. A l'époque, les langages de plus haut niveaux n'avaient pas totalement fait leur preuve. De plus, je pense que c'est le langage préféré d'Ethan tout simplement. Cette implémentation est bien faite, mais avec du C point de miracle, c'est long à gérer et les possibilités d'erreurs sont multiples. Penser à un pool de process en C effraie, moi le premier. Mais c'est faisable en C avec pas mal d'efforts et de tests, Apache l'a bien fait. Mais dans les langages de plus haut niveaux, les Poll de threads ou de process sont livrés en standards, déjà débuggé et performants.

Ce n'est qu'un exemple parmi tant d'autres sur l'intérêt d'utiliser de tel langages. Bien sûr, si vous voulez coder un driver pour un noyau, un tel langage n'a aucun intérêt, ce n'est pas leur cœur de cible. Mais un scheduler qui a besoin d'être très modulaire l'est. Même un scheduler qui lance des sondes à tout bout de champ.

La solution à la stagnation de Nagios est de passer par un tel langage. Changer quelque chose avec une telle implémentation est faisable, voir même agréable (pas de compilation, langage qui ne pique pas les yeux...). C'est là qu'intervient Shinken. Il était un proof of concept, il devient une proposition pour une nouvelle implémentation. A titre d'exemple, rajouter un attribut a un objet (en gérant l'héritage, la valeur par défaut and co) revient à rajouter une ligne dans le code de Shinken, là où il en demande bien plus dans Nagios. Avoir une idée ne coûtera plus 2h de code, mais quelques secondes.

NOTE 2021: juste un language qui gère l'héritage, car purée quelle plaie le code de Nagios en C où il faut coder les algos 3 fois...
           par contre je relancerai le projet aujourd'hui, ça serait en rust pas en Python ^^

La proposition

J'ai proposé dans la mailing list devel de Nagios il y a une semaine que Shinken devienne la branche développement pour Nagios 4. Les réponses sont limitées pour l'instant. Ethan ne s'est même pas donné la peine de répondre (lit-il encore cette mailing list?), Andreas va tester un jour. Je vais relancer un peu le sujet, mais j'ai de moins en moins d'espoir d'atteindre mon objectif.

NOTE 2021: Andreas a été débarqué du projet Nagios d'une manière bien moche par la suite. Il était vraiment un mec bien pourtant.

Un autre moyen sera de lancer un concurrent à Nagios, de mettre pas mal de coups de pieds au culs, puis de re-proposer l'inclusion. Mais combien de temps auront-nous perdu dans cette histoire?

NOTE 2021: et tu paies comment les salaires petit malin? L'auteur de Nagios a eu le même problème. SPOILER: sans gros moyen de lancement, l'open source n'est pas soutenable.

Jean Gabès