Journal Shinken, la refonte de Nagios en Python, sort en version 0.1

Posté par  (site web personnel) .
Étiquettes :
14
1
juin
2010
Bonjour cher journal,

Il y a quelques temps, je t'avais parlé du projet Shinken que je co-développe [1]. Sa première version officielle, la 0.1 est sortie [2].
Pour rappel, Shinken est une ré-implémentation de Nagios, cette star de la supervision Open Source. Ce dernier est codé en C, Shinken est en pur Python. Ce choix a permis de mettre en place facilement une architecture qui respecte la philosophie Unix (un outil par tâche) et qui s'oppose ainsi à la vue monolithique
de Nagios.

En plus de pouvoir réutiliser la configuration de Nagios ainsi que ses nombreux plugins de vérifications, il autorise l'utilisateur a monter un environnement distribué hautement disponible très facilement, d'avoir un support de l'UTF-8, de fortes performances par rapport à Nagios et enfin d'être multiplateforme.

Toutes les fonctionnalités de Nagios ne sont pas encore présentes, mais les quelques manquantes sont rarement utilisées. De nouvelles sont également déjà présentes comme la modification de retour de sonde à la volée en fonction de la période de temps, ainsi qu'une plus grande facilité de configuration des escalades de notifications.

Ce projet est encore jeune, et n'est donc pas destiné à investir vos serveurs de production à cours terme, mais cette version 0.1 est déjà bien avancée, et est disponible sous forme d'une machine virtuelle avec deux interfaces Nagios de visualisation pré-installées (Ninja et Thruk) [3].

Concernant l'aspect projet par rapport au Nagios originel, après un échec lors de la proposition en décembre dernier [4] d'inclusion du code dans une branche de développement, une autre tentative est en cours avec la participation à seedcamp [5], concours organisé par Nagios pour récompenser les nouveaux projets innovants gravitant autours de l'outil de supervision. En cas d'échec, le projet continuera sa route en tentant de garder le plus possible une compatibilité avec son grand frère.

Pour ceux qui s'interrogent sur l'architecture du programme, elle est présentées sur le site de la communauté francophone de la supervision open source [6], ainsi que bien sûr sur le site du projet officiel [7]. Elle fera également partie d'une conférence aux RMLL [8], raison de plus de venir sur Bordeaux début juillet.

Cher journal, j'attends avec impatience tes retours des tests de cette première vraie version.


Gabès Jean

[1] : http://linuxfr.org/~naparuba/29141.html
[2] : http://www.shinken-monitoring.org/news/the-0-1-version-is-ou(...)
[3] : http://www.shinken-monitoring.org/download/
[4] : https://sourceforge.net/mailarchive/message.php?msg_name=6f8(...)
[5] : http://www.nagios.org/seedcamp/
[6] : http://www.monitoring-fr.org/2010/06/shinken-sort-du-bois-la(...)
[7] : http://www.shinken-monitoring.org/the-global-architecture/
[8] : http://2010.rmll.info/Nagios-et-la-supervision-des-grands-en(...)
  • # Nom de code de la version

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

    J'ai oublié le nom de code de cette première version : Anemic Alligator. Ceci représente bien le potentiel de l'outil, mais qui a encore besoin d'un peu de temps pour arriver à maturité.
  • # Ca mériterai une dépêche non?

    Posté par  . Évalué à 6.

    Sinon, pourquoi le chois de Python ? N'est ce pas la nouvelle architecture du système qui fait gagner en performance? (je ne sait pas, ce n'est pas ma spécialité, je croyait juste le C plus performant (plus compliqué aussi...))

    Sinon, c'est très intéressant, si ce n'est les numéros entre crochets...
    • [^] # Re: Ca mériterai une dépêche non?

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

      Ah oui pour la dépêche, je vais rédiger et surtout compléter un peu plus alors.

      Le choix du Python est en fait une heureuse rencontre : je connaissais ce langage que j'apprécie beaucoup, et au début Shinken était un proof of concept pour Nagios, donc il me fallait un langage où on puisse coder vite (et bien), quitte à reporter le code en C plus tard dans Nagios.

      Il s'est révélé ensuite qu'il était plus simple (et efficace) de terminer le proof of concept avec ce qui lui manquait de Nagios que le contraire.

      Pour les performances en fait l'architecture permet d'avoir une distribution de la charge très facile, mais c'est surtout l'utilisation du module multiprocessing de Python >= 2.6 qui permet de gagner en performances tout simplement. Nagios passe une grande partie de son temps à forker/écrire des fichiers plats. Deux problèmes réglés avec ce module. D'où de meilleures performances tout simplement, pas de secret ici.

      Par contre je n'ai pas compris les numéros entre crochets. Ce n'est pas la méthode habituelle pour les liens?
      • [^] # Re: Ca mériterai une dépêche non?

        Posté par  . Évalué à 3.

        Ben si, mais les lien directe dans le journal ça le fait aussi. Par contre, je ne sait pas comment on fait. Mais rassure toi cela reste très lisible.
        • [^] # Re: Ca mériterai une dépêche non?

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

          Ah merci, car moi non plus je ne sais pas comment faire. Je suis en train de proposer une dépêche, quelqu'un va bien m'aider pour les liens.
          • [^] # Re: Ca mériterai une dépêche non?

            Posté par  . Évalué à 6.

            Comme ceci: <a href="http:// url">texte</a>
            • [^] # Re: Ca mériterai une dépêche non?

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

              Ah bah oui tout simplement.
              • [^] # Re: Ca mériterai une dépêche non?

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

                Sauf que c'est pratique d'avoir les lien en bas ..
                - Ça permet de recopier le journal dans un fichier texte dans perdre les urls
                - Ça permet de repérer rapidement une url intéressante sans avoir à cliquer dessus

                Rien n'empêche d'avoir les deux par contre :).
                • [^] # Re: Ca mériterai une dépêche non?

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

                  > Rien n'empêche d'avoir les deux par contre :).
                  ha oué, les deux alors
                  car les liens dans les notes, c'est bien gentil pour du copier coller, de l'impression, toussa (des techniques d'un autre âge quoi...)
                  mais pour lire dans un navigateur, c'est quand même 'achement bien quand on a pas à scroller car on veut juste savoir ce qu'il y a derrière ce '[1]' pour ensuite se perdre en remontant. Niveau confort de lecture c'est assez moisi.

                  \begin{minute c'était mieux à vent}
                  pourtant, il y a pas si longtemps, on ne voyait que peu ces notes issues du monde de l'édition papier.
                  \end{minute c'était mieux avant}

                  Autant je trouve intéressant d'avoir quelques liens en bas d'un journal pour les retrouver aisément, autant je trouve assez nul de ne faire que ça
      • [^] # Re: Ca mériterai une dépêche non?

        Posté par  . Évalué à 2.

        mais c'est surtout l'utilisation du module multiprocessing de Python >= 2.6 qui permet de gagner en performances tout simplement

        Comment fonctionne shinken avec python 2.5 (celle de debian ;-) ) ?
        • [^] # Re: Ca mériterai une dépêche non?

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

          Il ne fonctionne pas. Tout comme avec la version standard sur RedHat5 et assimilé. Mais même pour cette dernière, la mise en place de Python 2.6 est facile.
          • [^] # Re: Ca mériterai une dépêche non?

            Posté par  . Évalué à 1.

            multiprocessing à été porté pour python 2.4 et 2.5.
            http://code.google.com/p/python-multiprocessing/
            • [^] # Re: Ca mériterai une dépêche non?

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

              Ah oui c'est vrai, mais revenir sur la syntaxe des exceptions en as fait que le code devient tout de suite moins joli. Je reconnais que ce n'est pas un critère de premier ordre, mais moi j'aime bien ne pas avoir à détourner le regard quand je regarde mon code :p

              Si quelqu'un se lance dans une migration vers 2.5 pourquoi pas, mais bon, dès que debian sera passé à une Python un peu plus à jour, on pourra revenir à une version plus sympathique.

              Par contre là on parle pour l'écosystème GNU/Linux. Quelqu'un sait quelles sont les versions de Python classiques (entrendre en standard) pour les autres Unix (genre les Unix dont les noms commencent par un A ou un H)?
              • [^] # Re: Ca mériterai une dépêche non?

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

                Sous Mandriva 2010:

                [pointal@murmure ~]$ python --version
                Python 2.6.4
                [pointal@murmure ~]$ python3 --version
                Python 3.1.1

                Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

  • # Licence

    Posté par  . Évalué à 2.

    En parcourant le site internet du projet j'ai constaté que le code est sous licence AGPL. J'ai du mal à comprendre la motivation de ce choix. Nagios est utilisé en passant par une interface web, mais je vois mal une entreprise donner un accès publique à cette interface... Donc le projet aura du mal à demander les modification apportées au projet (Si l'utilisation reste interne à l'entreprise et qu'il n'y a pas d'utilisateur externe).

    Je me trompe ?
    Quels sont les motivations de se choix ?
    La GPLv3 n'aurait t'elle pas suffit ?
    • [^] # Re: Licence

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

      Si c'est un boitier en location, ou l'interface que tu file à tes clients ?
      • [^] # Re: Licence

        Posté par  . Évalué à 1.

        Oui, c'est sûrement le meilleur cas d'utilisation de cette licence!
        J'ai toujours du mal à comprendre l'intérêt de cette licence pour un site internet publique. Je vois mal quelqu'un choisir un projet où il peut être assaillit de courriel lui demandant le code source de l'application... Même si ce problème peut être résolu en créant un site web proposant les sources... Mais créé un site web pour distribuer les sources d'un site web... ça tourne un peu en rond.
        C'est pour ça que je voulais comprendre le choix de l'auteur.
        • [^] # Re: Licence

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

          En même temps, il suffit juste de dire "j'ai pris les sources de tel site web qui est le site de l'upstream", et voila. Et franchement, je pense que la majorité des gens vont jamais demander le code d'un site web ni rien.
    • [^] # Re: Licence

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

      C'est en effet la AGPL qui s'applique (sauf pour la documentation récupéré de Nagios, donc GPLv2). En fait je me suis mis du point de vue client qui se voit surveillé par un prestataire qui utilise l'outil : c'est libre il le sait, mais il n'a pas accès au code utilisé pour le superviser si c'est du GPLv3 standard. Le client doit avoir accès à ça, d'où la AGPL.

      Ensuite ce n'est pas rédhibitoire car ceci ne concerne que le coeur de l'application, pas les sondes de supervision. Hors dans la quasi totalité des cas, c'est elles qui font la vraie plus value du prestataire avec l'organisation qui va autour.
  • # une autre tentative est en cours

    Posté par  . Évalué à 4.

    >>après un échec lors de la proposition en décembre dernier [4] d'inclusion du code dans une branche de développement, une autre tentative est en cours avec la participation à seedcamp [5], concours organisé par Nagios pour récompenser les nouveaux projets innovants gravitant autours de l'outil de supervision.

    En parcourant les échanges du lien [4] la résistance à ton projet me semble très forte.

    Pourquoi penses tu que participer au concours te donnera plus de change d'être accepté ?
    • [^] # Re: une autre tentative est en cours

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

      La résistance a été forte, c'est un fait. Le soutient aussi, même si moins affiché. Par contre une personne n'a jamais donnée son avis, que ce soit officiellement ou non : l'auteur de Nagios tout simplement. C'est l'occasion pour lui d'accepter ce qu'on lui offre. Il a presque tout à y gagner en fait. C'est pour ça qu'il y a des chances que ceci réussisse.
      • [^] # Re: une autre tentative est en cours

        Posté par  . Évalué à 4.

        J'ai l'impression que tu as changé de point de vu sur le python depuis que tu nous en a parlé la première fois. Accepterais tu que Nagios intègre ton code avec réécriture en C ?

        N'y vois aucune critique c'est juste pour mieux comprendre ce qui se trame.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: une autre tentative est en cours

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

          Ah? Je ne crois pas que mon avis sur Python ait tellement changé. Peut être que je me suis mal exprimé.

          En fait le but de Shinken au début était exactement celui-là : faire un test rapide en Python, puis porter en C.

          Mais en prenant un peu de recul face à la facilité de porter Nagios en Python je me suis demandé quel serait le meilleur langage pour Nagios justement. C'est un ordonnanceur (donc gérer des dates et temps) qui lance des sondes (popen sur un script ou exécutable) et qui réagit au résultat (autre popen).
          Est-ce une problématique bas niveau? Je ne pense pas. Gérer le temps n'est pas un problème de calcul très violent, surtout en utilisant un peu de cache sur les calculs lourd (5 lignes...). Le popen? Et bien le module pour en Python est très efficace et pratique à utiliser.

          Je ne dit pas que c'était une erreur de coder Nagios en C il y a 10ans, car c'était le meilleur compromis pour avoir une grosse communauté. Mais maintenant? Le Python s'est fortement démocratisé (il n'y a qu'à voir les stats du langage sur ohloh) et offre une maintenabilité bien supérieure au C, sans pourtant sacrifier les performances.

          La migration est problématique, j'en ait conscience, et ce problème ne sera peu être jamais résolu que par une bête guerre de projet. Au pire j'échoue, mais le coup de pied au c%l du projet Nagios sera déjà ça de pris, car au moins désormais il avance un petit peu avec seedcamp par exemple.

          Si maintenant quelqu'un pense le contraire et porte mes idées en C pour le cœur, je ne vais pas lui jeter les pierres, bien au contraire. Mais je ne ferai pas ce travail moi même tout simplement. Je sais qu'une partie de ce que j'ai proposé est en cours de réalisation depuis quelques temps (le pool de process). Mais ce n'est qu'une partie de ce que Shinken apporte. Et au vues du temps que ceci prends, je pense avoir raison de rester sur Python.

          L'avenir nous dira qui a raison. Au pire, en cas d'échec de ma part, j'aurais fait bouger Nagios et je me serait bien marré en codant en Python.
          • [^] # Re: une autre tentative est en cours

            Posté par  . Évalué à 2.

            vraiment intéressant comme projet.

            Quid d'ouverture pour plug ins, customisations, automatisations via du code externe en Python ?
            • [^] # Re: une autre tentative est en cours

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

              En fait c'est déjà le cas pour la partie module du daemon broker qui fait l'export des données (par exemple en MySQL ou Oracle). Ce n'est pas encore documenté par contre, mais les exemples de modules sont très simples à comprendre.

              Ce type de module devrait arriver dans les autres daemons également. On peut imaginer par exemple un module pour l'Arbiter, qui est chargé de lire la configuration, module qui lirait la configuration en base plutôt qu'en fichier plat par exemple.

              Un autre exemple de module serait pour le daemon poller qui est chargé de lancer les sondes. Un module pourrait être un python embarqué comme il existe du Perl embarqué pour Nagios, ou bien un module natif NRPE qui aurait de meilleures performances que de faire un popen par exemple.

              Mais pour ça, il faut que je définisse comment les modules sont intégrés à ces daemons. Je prends toute aide/expérience sur ce point, comme sur tous les autres d'ailleurs.
          • [^] # Re: une autre tentative est en cours

            Posté par  . Évalué à 3.

            qui lance des sondes (popen sur un script ou exécutable) et qui réagit au résultat (autre popen).

            Y'a justement un journal où justement on précise que ces méthodes sont obsolètes, et qu'il faut utiliser subprocess.

            Après certains en déduisent que Python est mauvais...

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: une autre tentative est en cours

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

              Hé bien ça tombe bien, voici l'appel en Python dans le code :
              self.process = subprocess.Popen(shlex.split(self.command), stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True)

              Je trouve le module subprocess bien plus pratique à utiliser que les vieux popen (qui sont de toute manière toujours présent) :)

              Le journal en question n'était-il pas un pauvre troll qui a peur devant la montée en puissance de Python au cours de ces dernières années? Mais bon un troll reste un troll, il ne cherche pas à argumenter après tout.

Suivre le flux des commentaires

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