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(...)
Journal Shinken, la refonte de Nagios en Python, sort en version 0.1
1
juin
2010
# Nom de code de la version
Posté par Jean Gabes (site web personnel) . Évalué à 8.
[^] # Re: Nom de code de la version
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 10.
[^] # Re: Nom de code de la version
Posté par grid . Évalué à 2.
C'est une longue tradition de nom débile :)
# Ca mériterai une dépêche non?
Posté par Olorim . Évalué à 6.
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 Jean Gabes (site web personnel) . Évalué à 6.
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 Olorim . Évalué à 3.
[^] # Re: Ca mériterai une dépêche non?
Posté par Jean Gabes (site web personnel) . Évalué à 1.
[^] # Re: Ca mériterai une dépêche non?
Posté par __o . Évalué à 6.
<a href="http:// url">texte</a>[^] # Re: Ca mériterai une dépêche non?
Posté par Jean Gabes (site web personnel) . Évalué à 1.
[^] # Re: Ca mériterai une dépêche non?
Posté par Corentin Chary (site web personnel) . Évalué à 2.
- Ç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 CrEv (site web personnel) . Évalué à 6.
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 Flyinva . Évalué à 2.
Comment fonctionne shinken avec python 2.5 (celle de debian ;-) ) ?
[^] # Re: Ca mériterai une dépêche non?
Posté par Jean Gabes (site web personnel) . Évalué à 2.
[^] # Re: Ca mériterai une dépêche non?
Posté par Jean B . Évalué à 1.
http://code.google.com/p/python-multiprocessing/
[^] # Re: Ca mériterai une dépêche non?
Posté par Jean Gabes (site web personnel) . Évalué à 2.
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 lolop (site web personnel) . Évalué à 2.
[pointal@murmure ~]$ python --version
Python 2.6.4
[pointal@murmure ~]$ python3 --version
Python 3.1.1
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Licence
Posté par mathgl . Évalué à 2.
Je me trompe ?
Quels sont les motivations de se choix ?
La GPLv3 n'aurait t'elle pas suffit ?
[^] # Re: Licence
Posté par Misc (site web personnel) . Évalué à 6.
[^] # Re: Licence
Posté par mathgl . Évalué à 1.
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 Misc (site web personnel) . Évalué à 1.
[^] # Re: Licence
Posté par Jean Gabes (site web personnel) . Évalué à 3.
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 Kangs . Évalué à 4.
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 Jean Gabes (site web personnel) . Évalué à 4.
[^] # Re: une autre tentative est en cours
Posté par barmic . Évalué à 4.
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 Jean Gabes (site web personnel) . Évalué à 2.
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 kezako . Évalué à 2.
Quid d'ouverture pour plug ins, customisations, automatisations via du code externe en Python ?
[^] # Re: une autre tentative est en cours
Posté par Jean Gabes (site web personnel) . Évalué à 1.
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 zebra3 . Évalué à 3.
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 Jean Gabes (site web personnel) . Évalué à 4.
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.