Jean Gabes a écrit 459 commentaires

Bravo c'est un joli résumé :)

Oui, mais avec une interface et une archi qui lie le tout qui elle est livrée avec un fichier licence qui n'a rien de GPL... :(

Nagios XI est une déception en soit car bons nombres d'innovation attendu pour le Core ont été encapsulé dans Nagios XI donc payant.

En fait le vrai problème avec XI n'est pas qu'il est payant (ça c'est limite bien, ça fait des sous pour Ethan, il peux continuer à bosser sur Nagios), mais que c'est une appli propriétaire montée sur des applications open sources. Alors légalement je pense qu'il respecte les licences, mais éthiquement c'est moyen, et ça ne laisse présager de rien de bon pour la partie qui est toujours open source. Et c'est bien ça qu'on veut lui demander avec tant de fracas il est vrai : la partie open source est-elle vouée à mourir oui ou non?

Pourtant c'est le cas, mais ils doivent maîtriser encore moins que moi...

Nagios a un site que je trouve très pratique : les personnes proposent des idées, et les autres votent pour ou contre. Vu que la lettre ouverte est postée sur la mailing list de Nagios et qu'il n'est pas certain que l'auteur la lise encore, je me suis permis de proposer une nouvelle idée : répondre à la lettre ouverte de la communauté :)

Pour ceux qui souhaitent supporter notre démarche, vous pouvez apporter votre voix sur :
http://ideas.nagios.org/a/dtd/22035-3955
(pas besoin d'avoir un compte pour voter).

C'est très sadique, j'aime bien l'idée. Mais pour l'instant évitons d'envenimer la situation, car nous souhaitons une réponse de l'auteur, pas de ses avocats :p

En effet je souhaite que Nagios continue. Si c'est avec mon code je ne vais pas cracher dessus c'est clair, mais là c'est bien plus que ça. Il y a eu tant d'effort et de travail, tant de l'auteur que de la communauté, qu'il serait dommage de tout gâcher.

Si l'auteur souhaite quitter la sphère open source on n'a pas le droit d'exiger de lui de rester, mais au moins qu'il le dise clairement, que le projet open source puisse évoluer. Un mail, c'est tout ce qu'on lui demande. Là le manque total de communication de sa part bloque le projet dans son ensemble, et on y perd tous, lui y compris.

Pour ce qui concerne mon projet, je tiens au code, car j'y ai vraiment travaillé, par contre être le chef d'un projet n'est pas dans mon objectif (ni dans mes qualités j'en ai peur), d'autres le font bien mieux que moi, et si je peux le faire intégrer à Nagios tant mieux, tout le monde en profitera.

Mais là justement il refuse toute aide de la communauté. Il ne réponds même pas à une proposition majeure sur l'avenir du projet avec une nouvelle ré-implémentation qui lui offrirait une gestion native de la supervision distribuée hautement disponible. Il ne réponds plus sur toutes les propositions, même celles qui vont directement dans son sens business, et ça c'est inquiétant.

Un bon moyen également est de suivre les conseils de http://www.framablog.org/index.php/post/2010/02/08/comment-d(...)

Il faut faire attention que le filesystem soit bien aligné avec les blocks sur le disque, sinon chaque accès se paye double (bon le secteur n'est pas loin, c'est déjà ça) non?

Bon vu les débats, finalement un journal c'était pas mal. Après avoir lu cela, j'ai beaucoup plus de respect pour les juristes qui s'occupent de la propriété intellectuelle, car mine de rien, ce n'est pas si simple.

Merci pour la suggestion, mais en fait je n'ai pas de problème de performance particulier en restant en pure Python. Là où Nagios est limité par son architecture (lecture de fichiers plats) mon implémentation est plutôt limitée par les lancements de sondes (et là bah C ou Python, faut bien le faire le popen :) ).

Il y avait à un moment une grosse limitation sur le calcul de la date du prochain lancement des vérifications (les possibilités de périodes de temps dans Nagios sont vastes, et les calculs non triviaux) mais je l'ai fait disparaître avec un cache tout simple :)

Il y a encore des optimisations à faire dans le code (certaines opérations qui peuvent être mise en cache au lieu d'être effectuée à chaque lancement par exemple), mais déjà les performances permettent de gérer un très gros parc sur un seul serveur, donc le tuning attendra encore un peu.

Je suis plus qu'attaché au Python.Sur la mailing liste de Nagios je me suis demandé s'il y avait encore moyen de tout refaire en C, mais c'est trop pour moi en tout cas. Donc comme je l'ai récemment dit dans cette même mailing liste, cela restera du Python, que cela plaise aux développeurs Nagios ou pas (et pour l'instant c'est surtout ou pas).

Il n'est pas encore utilisé en production, mais je commence à le mettre en qualification sur mon infra (taille moyenne avec 7000 services, mais dispatchée sur 40 filiales dans le monde).

Reçu. Le même dépôt peut être pratique car je compte inclure dans la doc de nouvelles pages (sur les architectures distribuées qui sont la réelle avancée du projet en fait) avec de jolis diagrammes tout pleins (moi si je n'ai pas un dessin, j'ai tout de suite beaucoup à plus de mal à comprendre). Je vais faire référence dans les commentaires du code à ces diagrammes afin qu'un lecteur puisse se représenter facilement où il est, et quels sont les points importants du code (ce qui est le vrai cœur, de ce qui ne l'est pas).

Encore merci pour tous ses conseils.

Merci de cette explication.

En fait la doc va être mise en docbook, ce qui sera distribué sur le site sera le pdf ou HTML généré à partir de cela. La source du docbook étant le HTML de Nagios, il prend la même licence.

Question pratique, si j'arrive à obtenir le fait que la doc de Nagios est GPLv2, je peux tout mettre dans un même repository git?

J'avoue que le mix de licences a toujours été un peu flou dans mon esprit.

Merci pour le lien, c'est très pratique.

Une solution à mon problème pourrait être de passer en GPLv2 or later et à terme (une fois toute la doc réécrite en gros) et que l'inclusion dans Nagios (GPLv2 only) n'est pas faisable, je passe en GPLv3, voir plus.

Merci beaucoup pour toutes ces remarques.

1 : il semblerait bien oui
2 : là ça va me poser un problème :(
3 : problème avec le 1 en effet
4 : en fait je n'ai fait que reprendre les idées, aucune ligne de code ni librairie. C'est une réécriture pure (d'où le fait que je me suis permis de prendre une nouvelle licence au passage).
5: ah je n'avais pas pensé à cela.
6: oui

Ce qui m'intéresse dans Nagios est bien sa doc, et uniquement sa doc. L'objectif de mon projet est de réintégrer un jour le projet Nagios si ses développeurs l'acceptent. Je vais essayer de voir avec eux ce qui est possible de faire (on est en désaccord, mais pas fâchés tout de même).

Passer en GPLv2 est possible, mais ça m'embête un peu de lâcher la partie Affero. Je vais en parler aux autres développeurs car après tout, il faut l'unanimité sur ce point.

Merci en tout cas.

Bon bah c'est décidément pas un seul café qu'il me faut le matin moi....

C'est juste qu'elle ne sera pas autant testé que Nagios, loin de là. Ensuite suivant son adoption et les retours de tests, on pourra la faire progresser rapidement ou pas vers la 1.0.

Désolé du bruit, j'ai écrit avant de prendre mon café...

Pour que ce journal ne soit pas totalement inutile, je vais en profiter pour parler de l'avancée de ce projet que j'ai déjà présenté dans un précédent journal.

Shinken est une réécriture complète de Nagios en Python permettant d'avoir une supervision distribuée et hautement disponible. La 0.1 arrive sous peu, et possèdera environs 90% des fonctionnalités de Nagios, et 100% des fonctionnalités les plus utilisées.

La partie distribuée et hautement disponible est déjà parfaitement utilisable. Le travail actuel se concentre sur les exports de données dans les différents format que supporte Nagios (comme Ndo/Oracle ou Merlin/MySQL).

L'import de ce projet comme nouvelle branche de développement de Nagios n'a pas été possible (pour l'instant) à cause d'un refus catégorique des dev de Nagios de lâcher le C. Mais je ne perds par espoir car Nagios avance de moins en moins, et l'évidence leur sautera bien aux yeux un jour.

Ceux qui veulent suivre ce projet peuvent se rendre sur son site [1] ou son trac [2].

[1] http://www.shinken-monitoring.org
[2] https://sourceforge.net/apps/trac/shinken/report/2

C'était mon idée au début de ce projet : prototyper en Python, puis porter en C. Mais j'ai été un peu trop loin, le retour en Full C va être complexe et long. Et pour quel gain? Là on parle de développeurs qui ont peur de changer. Les anciens utilisateurs vont voir leur habitude légèrement changer (ils gardent la même conf, mais au lieu d'avoir un daemon, ils en ont plusieurs même si au jour le jouir, un seul les intéressent).

Ce qui est complexe c'est l'intégration avec le projet existant. Mais le prix pour avoir un outil autrement plus flexible et apte à contrer ses concurrents est bien celui-ci. Si tu prends un Zenoss par exemple, ce n'est pas pour rien qu'il évolue très très vite.

S'il faut passer par un nouvel outil indépendant c'est dommage mais j'irai. Je n'irai sur cette voie que si je n'ai pas d'autres solutions. Je suis prêt à des concessions, mais Nagios a suffisamment stagné. Il est temps de repartir sur de meilleurs bases pour affronter les problématiques de la supervision qui ne sont plus les mêmes qu'il y a 10ans.

C'est vrai que cela ne m'a même pas effleuré l'esprit. Sur la totalité de mes serveurs il est installé de base, mais certains OS ne l'on pas en standard il est vrai.

Je suis en discussion sur la mailing list Nagios pour voir ce que l'on fait de shinken : branche de Nagios ou pas? Avant que ce soit tranché, je n'ouvre pas les hostilités de ce qui ressemblerait à un Fork. Si je peux faire accepter Shinken comme une branche de Nagios (genre long-term-dev) je préfère. Ça devrait se décanter rapidement je pense.

En fait jusqu'à il ya une bonne grosse semaine, un poller était constitué de N workers qui sont un Poll de process pour Poller. Chacun lançait un et un seul check à la fois. Il "pollait" (oui ça fait beaucoup de poll ;) ) régulièrement la sonde lancée pour voir si elle était en vie.
Le problème c'est que Python ça consomme un peu de RAM (non non, c'est vrai). Donc pour avoir 200 sondes en parallèles, il fallait 200 workers de 10Mo chacun. Ca commence à faire mal.

C'est pourquoi j'ai diminué le nombre de worker, mais chacun peu lancer un certain nombre de sondes (par défaut 256, mais c'est configurable et surtotu limité par la limite sur le nombre de fichiers ouverts en même temps sur ton système). Il lance puis va poller régulièrement de la même manière chaque sonde. C'est un peu ce que tu proposes justement :)


Pour le bypass du exec, je pense que le "moins pire" serait de déterminer au niveau du scheduler quel "plugin" utiliser suivant la tête (regexp) de la commande (ou bien si c'est direct dans le check_command, mais bon...). Il place l'info dans le check à effectuer, et le poller le fait gentiment. Si pas d'info de plugin, il exec().

Ici le "plugin" est une sorte d'addon pour les daemons en gros. Pour l'instant seul celui qui récolte les informations en utilise, mais à terme d'autres vont en avoir :)

Oui changer le coeur, et uniquement le coeur et bien l'objectif.

Icinga je suis en pourparlé avec eux, mais ils ne semblent pas partant pour lâcher l'ancien code. dommage. OP5 je ne sais pas, un de leur dev est en train de tester Shinken pour voir.

toute cette histoire risque fort de partir en Fork. Mon objectif est de ne pas m'éloigner trop des fichiers de conf de Nagios (bon un peu, j'ai de nouveaux objets à déclarer) pour qu'une fusion, si elle peu se faire "politiquement", se fasse sans trop de problèmes.