Jean Gabes a écrit 439 commentaires

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 :)