Jean Gabes a écrit 423 commentaires

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.

Et pourquoi on ne ferrait pas les deux? Après tout, la source de la configuration peut être une option non? L'administrateur est assez grand pour savoir ce qu'il veut. Certains on l'air d'aimer les conf en fichiers plats (je suis dedans), d'autres en annuaire ou même en base de données. Nagios s'est limité aux fichiers plats, mais pourquoi on ne lui permettrait pas de faire plus sans lâcher l'ancienne lecture de conf en fichier plat.

Oui, c'est ce que je pense aussi. La réposne d'Ethan, si on en a une.., sera négative d'après ce qu'a dit Marc Powell. Il faut bien voir que je n'ai pas sorti Shinken comme ça du jour au lendemain concernant les core dev. Ceci fait un petit moment que je leur présente les idées avec une preuve à l'appui qu'elles fonctionnent. Je me suis fait envoyer sur les roses à chaque essaie.

A un moment, il fallait faire un électrochoc, la mailing list me tendait les bras. Je pense qu'il est plus rapide de compléter Shinken que de reprendre ses idées et de les incorporer dans l'implémentation actuelle. J'ai peut être tord, mais qu'au moins les core dev prennent position et disent clairement ce qu'ils en pensent. S'ils disent qu'ils sont partant et motivés pour m'aider à prendre les idées et les incorporer au Nagios actuel, c'est parti.

Je pense qu'Ethan est très orienté XI (close source) en ce moment. On ne le reverra pas sur la mailing avant un moment, et les annonces qui tendent à lui couper l'herbe sous le pied des modules close source qu'il voulaient pour XI ne vont pas lui plaire. Et c'est exactement ce qu'est cette annonce.

Merci, toute aide sera acceptée avec plaisir :)

Avec une bonne utilisation des techniques d'héritage de conf, c'est parfaitement gérable (et pas que les modèles, mais vraiment toutes les techniques d'héritages, notamment l'implicite).

On pourrait penser à une possibiltié de conf en base, mais lâcher la possibilité d'avoir sa conf en fichier plat est dangereuse. C'est pratique un fichier plat :)

Pour l'Arbiter oui, pour l'instant il est seul, mais je vais régler ça.

Pour le découpage scheduler/poller j'y ais beaucoup pensé dernièrement. Pour de toute petites sondes rapides, on a plus de perf si on se passe de poller. En effet, 60% de perfs consommées les sont dans ... l'échange des checks (et des exports de status vers le broker) avec des sondes qui ne font rien (juste sleep). Mais avec des sondes lourdes (du perl codé à la va-vite par exemple) là c'est la fin, il te faut plusieurs pollers par scheduler. Donc lorsque la charge des sondes devient plus importante que celle du transfert, pouvoir augmenter le nombre de poller est intéressant.

Ce découpage est violent par rapport à Nagios oui. Mais à mon goût il fallait séparer les rôles. C'est bien plus facile à maintenir comme ça je trouve. Ca fait un peu plus composants qui travaillent ensemble, et non pas un gros bloc monolithique.

Sinon merci :)

- La plupart sont très liés à Nagios, à part le poller/reactionner qui peut être utilisé pour lancer n'importe quoi en fait le tant que ce qui nous intéresse est un code retour et l'output. L'API est basique et basée sur du Pyro, mais on pourrait imaginer de placer la dépendance à un service comme optionnelle si d'autres veulent utiliser autre chose.

-Oui, un plugin ça attend. C'est pour ça qu'il faut en lancer plein. Mais même s'ils attendent 80% de leur temps, ils travaillent un jour tout de même :) Donc tu as tout de même une limite sur le nombre que tu peux lancer en parallèle. Ce nombre est complexe a déterminer suivant le tyype de sonde (certains sont très lent, d'autres non), ce qui complexifie le nombre que tu va autoriser à être en parallèle. J'essais justement de déterminer le niveau de "charge" du poller pour qu'il soit au max, mais pas plus.

On pourrait intégrer les plugins les plus courants dans le code du poller, suivant ce qu'il devrait lancer il utiliserait tel code natif python plutôt que de faire un exec(). Je n'ia pas encore trouvé de méthode facile çà utiliser pour l'utilisateur (il "décrit" le plugin à utilsier dans la conf de sa commande? On se base sur une reconnaissance de la commande en expression régulière?)

Le fait de dédier des pollers je ne suis pas sûr, car un poller pourrait avoir plusieurs types de workers (c'est eux qui on un nombre de process lancés en parallèles), donc le mix pourrait se faire là, sans trop de chanboulement.

Pour la compatibilité avec les plugins, c'est totale, pas la moindre inquiétude là dessus. La force de Nagios réside dans ses plugins, pas l'ordonnanceur. Pour la conf, Shinken vise pour l'instant du 90% de compatibiltié. Si il est inclu dans la branche officielle de Nagios, je viserais le 100% forcément, même si de nombreuses options sont inutiles.

J'ai préféré ne pas répondre à cet email là, le lâché de troll aussi tôt dans une discussion, ce n'est pas bon :)

D'ailleurs pour pouvez remarquer dans un des derniers emails l'apparition d'un sondage et sur une possibilité de choix originale qui je suis sûr à bien aidé à réveillé le débat :)

Merci.

Le choix est 80% sur mon goût pour le Python, 20% pour ses qualités intrinsèques.

Les capacités dynamiques de Python comme le rajout de propriétés d'un objet à chaud ou bien le fait de pouvoir vérifier qu'il a bien une propriété particulière est très pratique dans le contexte de Nagios (la configuration utilise des principes d'héritages d'objet, donc ça colle parfaitement aux capacités du langage).
Si tu rajoutes un module Python comme Pyro pour les objets distribués d'un très grande qualité, le fait que le langage a très bonne publicité et que je me retrouve dans le "zen de python" (les grands principes du langage), le choix était fait.

Il me semble que Erlang aurait pu être utilisé car l'architecture est très distribuée, mais j'ai préféré parier sur un compromis plus reconnu et avec une plus grande communauté.

Honte à moi. J'ai complètement zappé le lien :

https://sourceforge.net/mailarchive/message.php?msg_name=6f8(...)

Perl il y en a dans beaucoup de sondes utilisées par Nagios, et encore, mais pas par le daemon ni par le CGI. Je pense que le choix de PHP est pertinent. L'ancienne interface est très lourde en terme de maintenance de code. Pour l'instant Ninja est un très bon remplaçant de l'interface standard de Nagios, mais elle ne permet pas de gérer la configuration comme le fait Centreon par exemple. Regardons comment elle va évoluer, mais félicitons les auteurs, car c'est déjà un pas dans la bonne direction :)