Shinken : quel avenir pour Nagios? Shinken?

Posted in Nagios by Nap on December 9, 2009 5 Comments

Certains ont du 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.

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.

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.

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?

Related Posts:

Comments
  • Sylvain:

    La description que tu fais de nagios est bien triste mais réaliste. Nagios n’innove plus depuis plusieurs versions. Quelle est la solution sur le long terme ?

    Icinga fait en priorité des changements dans le cosmétique là où il faudrait améliorer le moteur. Je ne sais pas comment serait reçus shinken sur la liste de diffusion icinga ? (si tu postes, il va falloir que je m’y (ré)inscrive).

    Il y déjà de nombreux outils de supervision libres, forker n’est probablement pas une excellente idée. D’un autre côté, si la supervision répartie est intégrée dans nagios sous forme propriétaire, il n’y a plus de question à se poser : nagios est mort :-( . Il restera à trouver le projet vers lequel se tourner sur le long terme : icinga, zabbix, zenoss ou … shinken en autonome ???

    • Nap:

      Je vais poster chez Icinga pour voir, mais ils semblent très attachés à leur implémentation, et le manque de changement du cœur de leur côté est criant en effet.

      Je pense que l’on va avoir une période dure et sans merci, Shinken en autonome étant clairement le trublion de service. Je n’ai pas pour vocation de créer un N-ième outil de supervision. Dès que je peux faire accepter ma solution comme un nouveau Nagios(TM), on aura tous gagné (et perdu du temps mais bon), le libre en tout premier lieu.

      La vue d’un Nagios Community/Enterprise me hérisse le poil d’avance. Faisons en sorte de lui couper l’herbe sous le pied grâce à ce saut de génération.

  • lawl:

    Vue la tournure que prend le projet Nagios (une partie propriétaire), le peu d’évolution du projet même après les annonces faite suite au Fork et mon affection pour python (tous mes plugins/rapports de supervision son en python)je ne peu qu’être heureux de voir un tel projet naître.

    @Sylvain:
    Au contraire, je crois qu’il y a justement maintenant une place pour un fork de Nagios.
    Pour les raison cité au dessus et parce qu’Icinga a été décevant alors que Shinken me parait prometteur.

  • SaeZ:

    Je suis heureux de voir que tu essaies de faire avancer Nagios, seulement, cela métonnerais qu’Ethan prenne en considération ce que tu lui proposes. Pour moir, ce que tu fais est extraordinaire, mais ne pourra pas être intégré dans Nagios.
    En effet, le coup de pied au derriere qu’a mis Icinga au derriere d’Ethan n’est apparement que temporaire.
    Cela crêve pourtant les yeux que la communauté atend plus qu’une refonte de l’interface, nous attendons un Nagios qui ne serait plus soumis au crtiques du genre “Centralisation inexistante (ou presque)”, “Problèmes de performance”, “temps d’implémentation des bugs”.
    Je ne suis pas un grand developpeur, mais je suis un admin qu a plus de 800 machines à superviser et passe trop de temps à se creuser la tête sur des problèmes liés au foNctionnement de nagios que Shinken peut résoudre.
    Quand on voit que tu peux le faire tourner sur un Windows, finit la phobie de Linux pour les administrateurs de PME, qui ne font que très peu de Linux, rien que cela est une énorme avancée parimis tant d’autre que tu proposes.

    J’ai bon espoir que Shinken soit la solution, si (un jour peut être) j’ai du temps, j’essaierais de mettre en place un solution parralele a l’infra nagios distribuée pour comparer les perfs et te faire un retour.
    Il se peut que Shinken devienne un produit a part entiere si l’on arrive a faire un retour assez conséquent.

    Continues sur cette voie la, tu tiens le bon bout.

    • Nap:

      Merci beaucoup de tous vos encouragements :)

      J’ai peu d’espoir d’une inclusion à court ou moyen terme de la part d’Ethan. Pour lui il faudra lui paser sur le corps avant je pense. Andreas est bien plus ouvert, il n’est pas impossible qu’a moyen terme ça passe grace à lui.

      Mais en tout cas je ne lache rien, j’avance, à eux de suivre s’ils le veulent.