Bonjour cher journal,
Je t'écris pour te signaler que dernièrement j'ai fait une proposition étonnante sur la mailing list de développement de Nagios. Je propose ni plus ni moins que de changer l'implémentation en C du cœur de Nagios par une nouvelle faite en Python qui est plus rapide et plus modulaire. Le changement d'implémentation ne change rien pour les utilisateurs qui peuvent toujours utiliser leur même fichier de configuration Nagios.
Pour rappel Nagios est un logiciel de supervision, considéré encore comme le maître en la matière dans le monde open source, même si ses concurrents comme Zabbix ou Zenoss commencent à le rattraper.
Le contexte de la nouvelle implémentation
Ceux qui ont suivi un peu l'histoire de Nagios ces derniers temps savent que ses évolutions ont été très limitées.Même après un Fork peu suivi, le projet n'a pas repris un nouveau souffle. C'est pour cette raison qu'il y a quelques mois j'ai commencé à coder un proof of concept pour de nouveaux modes de fonctionnement de Nagios comme le découpage des rôles en processus séparés ou bien la mise en place d'un pool de processus pour le lancement des sondes. Ce projet au nom de Shinken a rapidement évolué et s'est révélé, à ma grande surprise, bien plus rapide que Nagios lui même.
Les intérêts de la nouvelle implémentation
La partie architecture globale de l'application est également très innovante par rapport à Nagios. Ce dernier est monolithique : il lit la configuration, ordonnance les vérifications, les lance lui même
ainsi que les notifications. Ce mécanisme est suffisant pour une majorité des cas amis bien insuffisant pour les grands environnements.
En effet, Nagios est capable de lancer environs 10000checks en 5 minutes avec une configuration standard et 30000 avec des paramètres de tuning. Ce sont de bonnes performances, mais insuffisantes lorsque le nombre d'hôtes supervisés devient importants. Shinken arrive à monter à plus de 150000checks en 5 minutes en supprimant les goulots d'étranglements liés à la conception même du démon Nagios actuel qui repose sur la lecture de fichiers plats.
Lorsque les performances viennent à manquer, dans Nagios une solution consiste à utiliser plusieurs instances de Nagios travaillant ensembles, mais de nombreuses limitations subsistent quant à la gestion de la configuration et son envoi vers les différents Nagios et la difficile gestion de la haute disponibilité des Nagios. De plus, chaque Nagios gère ses propres notifications et données de performances ce qui complexifie grandement l'administration de la solution. Des solutions comme Centreon aident à la gestion de la configuration mais ne résolvent pas les problèmes de hautes disponibilités.
La solution de Shinken consiste à séparer les rôles de Nagios dans différents démons qui peuvent fonctionner sur des serveurs distincts, ces derniers pouvant se multiplier si le besoin de performances ou de haute disponibilité se fait ressentir et le tout avec très peu de changement dans la configuration !
L'un des autres avantages de la nouvelle architecture apportée par Shinken est d'avoir un seul point d'administration et de configuration : l'administrateur a une seule configuration à créer et gérer, elle sera découpée automatiquement par l'outil pour coller aux nombres d'ordonnanceurs disponibles. Il en est de même pour lancer des commandes externes : il suffit de la lancer à un endroit, et le démon va se charger de la redistribuer à qui il faut.
La proposition sur la mailing list
Les idées issues de ce proof of concept ayant déjà été rejetées offlist par les core développeurs ce Nagios car trop complexe à intégrer au cœur écrit en C, j'ai décidé de proposer de changer l'implémentation actuelle qui montre ses limites par une nouvelle basée sur son proof of concept bien plus performante et modulaire. Il est en effet plus simple d'améliorer son proof of concept pour lui rajouter les dernières fonctionnalités de Nagios qu'il ne gère pas, que d'apporter ses améliorations dans l'ancien code.
Pour l'instant les réponses à cette proposition sont partagées. Les core développeurs n'ont toujours pas pris positions sur une éventuelle inclusion dans la branche de développement.
Et toi mon cher journal, quel est ton avis?
Source : http://www.nagios-fr.org/2009/12/shinken-nagios-core-killler
Journal Nagios va-t-il quitter le C pour le Python?
10
déc.
2009
# URLs
Posté par Antoine . Évalué à 7.
Cela prouve en tout cas qu'un langage haut niveau comme Python permet de se concentrer sur les améliorations conceptuelles et peut in fine faire gagner de la vitesse, plutôt qu'en perdre.
[^] # Re: URLs
Posté par Jean Gabes (site web personnel) . Évalué à 6.
https://sourceforge.net/mailarchive/message.php?msg_name=6f8(...)
[^] # Re: URLs
Posté par Antoine . Évalué à 6.
« Personally if I'm to consider rewriting nagios in interpreted language I'd wait for Perl6 to come out, it'd be taken a lot better by nagios users. »
Perl 6, hum hum :-)
[^] # Re: URLs
Posté par Jean Gabes (site web personnel) . Évalué à 1.
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 :)
[^] # Re: URLs
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Si on regardait justement du coté de perl, le framework POE n'est-il pas proche de ce que tu as fait avec python ?
http://poe.perl.org/
[^] # Re: URLs
Posté par Moogle . Évalué à 4.
# Belle initiative
Posté par Dabowl_92 . Évalué à 5.
Revoir l'implémentation de fond pour améliorer les performances et l'administration, c'est comme ça qu'on rend un produit prêt pour l'exploitation/supervision de gros environnements et qu'on assure son avenir.
A la première lecture ce qui surprend, c'est de voir qu'un langage de plus haut niveau comme python, lorsqu'il est bien implémenté s'avère plus efficace qu'un langage de plus bas niveau mais avec une architecture vieillissante.
Cela montre bien que les choix techniques fait à un instant T dans un contexte C, ne sont pas forcément pertinent dans un temps T + 1 et avec un contexte "C + 1".
Maintenant pour satisfaire ma curiosité, j'aimerais savoir pourquoi le choix du langage s'est fait sur python, est-ce que par goût de l'auteur ou bien à la suite d'une sélection rigoureuse et exhaustive ?
[^] # Re: Belle initiative
Posté par ckyl . Évalué à 10.
La duplication de donnée, les indirections pourries et mal pensées, le code pas extensible, pas modularisable ou externalisable, ne pas pouvoir séparer les traitements, les abstractions chiottiques etc. ça coute beaucoup beaucoup plus cher en perf à terme... Après si tu appliques les même design/algorithme/structure de données avec un langage plus performant, ça ira plus vite, mais ça risque de couter un peu plus cher à faire ou un peu plus longtemps à stabiliser.
Bref rien de nouveau sous le soleil depuis le début de l'informatique !
[^] # Re: Belle initiative
Posté par Jean Gabes (site web personnel) . Évalué à 6.
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é.
[^] # Re: Belle initiative
Posté par totof2000 . Évalué à -10.
[^] # Re: Belle initiative
Posté par Octabrain . Évalué à 8.
[^] # Re: Belle initiative
Posté par totof2000 . Évalué à 3.
Ce serait quand même un signe de déficience mentale avancé que de faire du python tout en ayant des problèmes avec oython. Pour ma part, j'en ai fait, et j'ai arrêté parce qu'on passe son temps à déclarer des choses inutiles (je n'aime pas l'implicite de Perl qui pousse à écrire des progs crades, mais le tout explicite de python est un peu trop dans l'autre extrême).
En voulant "gommer" les défauts de Perl, Python est allé trop loin.
[^] # Re: Belle initiative
Posté par Antoine . Évalué à 2.
Je pense que Python et ses concepteurs n'en ont rien à battre de Perl :)
Tu penses peut-être à Ruby...
[^] # Re: Belle initiative
Posté par ccomb (site web personnel) . Évalué à 2.
[^] # Re: Belle initiative
Posté par lolop (site web personnel) . Évalué à 5.
Sinon, pour le côté verbeux, les self et tout ça, voir "The Zen of Python". A-priori tu n'es pas sur le même "zen" que les adeptes du serpent.
"The Zen of Python" (PEP 20): http://www.python.org/dev/peps/pep-0020/
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Belle initiative
Posté par ribwund . Évalué à 3.
# Tant qu'à utiliser un langage efficace ....
Posté par totof2000 . Évalué à -10.
[^] # Youpi
Posté par Octabrain . Évalué à 10.
[^] # Re: Youpi
Posté par totof2000 . Évalué à -6.
[^] # Re: Youpi
Posté par aedrin . Évalué à 3.
Ou alors version troll de combat urticant (genre plus c'est gros plus ça passe).
Mais visiblement tu as manqué d'ironie et/ou d'ambition... la prochaine fois peut-être ?
[^] # Re: Youpi
Posté par totof2000 . Évalué à 3.
[^] # Re: Youpi
Posté par Rémi Birot-Delrue . Évalué à -1.
# questions (réutilisations, multiplexage, compatibilité)
Posté par herodiade . Évalué à 5.
c'est un joli projet et j'espère que les autres devs seront receptifs.
J'ai quelques questions.
- Est-ce que les composants sont réutilisables sortis de l'ensemble?
par ex. peut-on réutiliser le parsing de conf pour faire autre chose? est-ce qu'ils ont une api "publique" ou seulement interne? (par ex. pour attaquer directement les scheduler et leur demander où ils en sont, changer leurs priorités, etc).
- En parlant de montée en charge ("scalability")...
comme le fait remarquer quelqu'un en réponse sur la m-l, l'essentiel de la durée d'execution d'un plugin type semble être passé à attendre (attente pour pouvoir écrire sur une socket, attente d'une réponse...) (plus le temps du exec() et envois du retour à nagios, bien sûr).
J'ai l'impression que l'execution des plugins en tant que commandes externes impose une limite au nombres de tests/seconde possibles : outre la surcharge de l'execution externe, en lancer un trop grand nombre simultanément (et même s'ils ne font pour ainsi dire rien d'autre qu'attendre, et quand bien même l'architecture à mutiple poller + NDX permettrai d'en lancer 10000 à la fois) signifirait saturer le/les système de processus sleeping.
Est-ce que des plugins très couramment utilisés comme check_tcp, check_http, et check_smtp pourraient être re-implementés en interne, et executés simultanément par multiplexage asynchrone et evenementiel de sockets ? par ex. en les regroupants quand c'est possible sur un seul (ou, disons, une poignée de) processus gerant x "checks classiques sur tcp ou udp ou raw (icmp)" et multiplexant via epoll()/kqueue() etc à la façon nginx/haproxy. Il existe plusieurs libs python pour faire ce genre de choses (twisted, mais il ne supporte pas IPv6, PyEvents, libevent-python...).
Le modèle des multiples pollers de shinken semble permettre ceci, au sens où avoir un couple de poller spécialisés/dédié aux checks de bases reposants sur tcp ne devrait pas empecher l'execution d'autres plugins en parralele (?).
- Quel est le niveau de compatibilité visé avec un nagios3 ?
seulement compatible au sens de pouvoir réutilise l'ancienne conf et certains plugins à condition d'y adjoindre des confs spécifiques à shinken ? générer un status.dat ? etc
[^] # Re: questions (réutilisations, multiplexage, compatibilité)
Posté par Jean Gabes (site web personnel) . Évalué à 1.
-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.
[^] # Re: questions (réutilisations, multiplexage, compatibilité)
Posté par herodiade . Évalué à 2.
C'est en fait dans ce cadre (toujours pour du Nagios) que je posais ma question ; à savoir : la possibilité de réutiliser un composant pour faire quelque chose d'autres (mais toujours relatif à nagios/shinken). Par ex. re-utiliser le parseur de conf, indépendamment du reste, pour faire un petit outil cli qui valide un changement, ou qui génère un hostexinfo.cfg automatiquement, ou qui fait un diagramme de gantt à partir des timeperiod, ce genre de choses quoi... Depuis j'ai regardé ton code et j'ai ma réponse (qui est: oui, c'est super modulaire, kewl :).
- [...] 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 [...]
C'est là que le multiplexage et le modèle évènementiel rendent service, justement. Il n'y a rien à déterminer à l'avance, le parallélisme est mis en œuvre par le noyau.
On peux donner autant de socket qu'on veut à un seul processus (même des centaines de milliers, si on utilise quelque chose de plus scalable que select(2), cf. haproxy par ex.), et ce processus travaille dès que l'une d'elles a des données dispos à lire. Au plus fort de la charge, le processus passe tout son temps (il utilise un cœur de cpu à plein) à faire les vrais traitements des données utiles en transit, aussi vite qu'il peut. Lorsqu'il n'y a rien à lire ou écrire, le processus dort. Dans tout les cas, et quelque soit le nombre de sockets dont il est responsable, le processus ne consomme que les ressources (ram et cpu) nécessaires au vrais traitements qu'il doit faire.
Un exemple : c'est pour ces raisons (une mainloop événementielle coté lighttpd et nginx vs. des pools de workers, threads ou forks, un pour chaque requète simultanée coté apache) que nginx et lighttpd ne sont pas affectés par le récent "slowloris", alors qu'apache s'écroule
Pour les mêmes raisons, lorsque plusieurs hôtes ne répondent pas aux requêtes, les plugins classique mais parallélisés vont sans doute occuper des ressources (x poller en attente + x * le plugin lui-même) jusqu'aux timeouts, et donc ralentir les autres traitements (si on essaie de maintenir un nombre constant/max de checks en cours) ou mettre le serveur de monitoring à genoux (si on ne limite pas), au moment ou justement on a besoin de monitoring précis et réactif parce qu'il y a des soucis sur le réseau.
De même, un processus dédié peut certainement gérer sans charge aucune quelques milliers de raw sockets pour envoyer/recevoir des pings en natif (sans "popen('/bin/ping'...)", mais il faut que le processus soit root ou la capabilty CAP_NET_RAW...) et avoir un résultat de check_host_alive à la seconde près sur un large parc. Dans le genre de http://gitorious.org/poe-component-client-ping .
Des docs pythoniques sur le sujet:
http://squirl.nightmare.com/medusa/async_sockets.html
http://docs.python.org/library/asyncore.html
http://docs.python.org/library/asynchat.html
- 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?)
C'est vrais, je ne vois pas non plus de moyen élégant pour substituer l'exécution des plugins connus/réimplémentés par une version ad hoc...
- Soit, comme tu dit, faire la substitution lorsqu'on reconnait un nom de plugin en arg d'une check_command... mais le parsing, berk
- Soit de façon déclarative (eg. "check_command check_tcp_shinken"). Moindre suprise, mais divergence avec une conf nagios brute.
- Soit de façon déclarative, dans un fichier de conf distinct et propre à shinken (genre shinken-specific.cfg), surchargeant la définition des plugins classiques. La aussi, ca fait une nouvelle divergence avec la conf nagios brute.
- Soit en fournissant un exécutable effectif (/usr/bin/check_tcp), qui au lieu d'effectuer le check lui-même, se contente de donner l'ordre de le faire au poller en charge des sockets, et retourne un code "maison" (qui signifierai : je n'ai pas le résultat, attends que le poller te le donne) (et/ou effectuerai le check lui même si et seulement si il n'a pas réussi à déléguer le check à un poller). Mais on ne s'affranchit alors pas de la surcharge inutile des fork()/exec()/popen() & reap, et puis c'est tarabiscoté ;)
Rien de totalement naturel et clean, effectivement.
- Le fait de dédier des pollers je ne suis pas sûr, car un poller pourrait avoir plusieurs types de workers
Effectivement, j'avais cru que les pollers se chargeaient de lancer les actions (pas vu le worker.py).
Désolé d'amener la discussion sur ces petits détails ; shinken semble déjà un super progrès par rapport à l'architecture de nagios :). La possibilité de faire tourner plein de checks classiques légers (tcp, http, udp, icmp) a intervalles très fréquents sans saturer le serveur de monitoring est peut-être un besoin plus perso qu'autre chose (mon serveur de monitoring fait tourner plein de trucs gourmands en plus de nagios, j'ai très peu de checks lourds en perl ou autre, et j'aimerai être avertis des problèmes plus vite qu'actuellement ...).
[^] # Re: questions (réutilisations, multiplexage, compatibilité)
Posté par Jean Gabes (site web personnel) . Évalué à 1.
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 :)
# Vachement gore
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Mais j'ai quand même remarqué un truc bien dommage : garder les fichiers de configurations originaux. Tant qu'à réécrire nagios, autant attaquer le problème à la racine. Je suis totalement d'accord que de garder la rétro-compatibilité est intéressant pour rendre les migrations moins douloureuses, mais dans ce cas je penses que c'est une erreur.
Les fichiers de configurations deviennent, à mon goût, ingérable rapidement (avec peu de hosts, services, ...), revoir ce point aurait été intéressant. Ces fichiers restes des fichiers qui contiennent énormément d'information et de garder des fichiers plats rend l'accès à cette information difficile. L'utilisation d'une base de donnée pour ça aurait été un vrai plus, mysql ou mieux un annuaire. De plus on aurait pu éliminer le "single point of failure" qui reste l'"arbitrer".
Ensuite il me semble qu'il y a sur-découpage des tâches. Je penses que le découpage schedulers/pollers est superflu. Ces deux éléments auraient pu être fusionner sans, à mon avis, trop impacter les performances.
Je dirais aussi que l'ensemble à l'air énormément complexe et effrayant, il y a plein de services qui sont nécessaire et chacun fait qu'un partie du travail. Un service indique l'action à faire, cette action est récupérée par un service qui fait l'action, le résultat est récupérer et stocker par un service et un autre service intervient pour faire les notifications. Il y a encore le service qui lit et transmet la configuration.
Ce que je me dis c'est qu'avec un système aussi complexe il faudrait peut-être un nagios pour surveiller que tous les services nécessaires à shinken tourne. C'est un peu l'impression que j'ai à lecture des documents.
Sinon joli travail quand même.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Vachement gore
Posté par Flyinva . Évalué à 4.
Le seul reproche que je ferais à nagios concernant les fichiers de configuration est de réussir à sortir simplement tous les paramètres de configuration d'un host ou d'un service. En effet, avec l'héritage, on est pas toujours certain du résultat et l'interface web n'aide pas.
[^] # Re: Vachement gore
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Oui, il y a des avantages aux fichiers textes. Mais au bout d'un moment il faut se dire qu'on duplique beaucoup trop les données sans gagner en haute-disponibilité. Je penses qu'en utilisant un système d'annuaire LDAP on peut facilement avoir :
- L'inventaire matériel
- Le serveur DNS
- DHCP
- Les services nagios à contrôler (donc la liste des services par machine)
- Les services ont des comptes utilisateurs, on uniformise donc les uid et gid à travers tout le parc
- ...
Je me rends compte que je passes de plus en plus de temps à faire des scripts qui vont pomper les informations dans le LDAP pour nourrir les différents services parce qu'au final ont a tout dans l'annuaire.
Avec le LDAP on a de la haute-disponibilité facilement, de la délégation (dans le cas des sites, ça se fonctionnerai très bien), ...
Par contre gérer l'historique c'est plus délicat, mais on a déjà les sauvegardes régulières qui font une sorte d'historique mais ça pourrait être mieux.
Faire l'équivalent dans une base de données, avec notamment la gestion des héritages, me semble très complexe mais je peux me tromper.
Un annuaire LDAP se prête bien à ça à mon avis.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Vachement gore
Posté par Florian . Évalué à 2.
C'est pourquoi, j'avais réfléchi à l'époque à un système pour simplifier la configuration et j'ai fini par développé un générateur de configuration pour Nagios. L'idée est de prendre un fichier XML en entrée et de sortir une config pour nagios.
L'avantage de mon fichier est l'ajout d'une notion assez puissante : les listes de services. En gros, je créé des listes de services qui contiennent plusieurs services, puis j'utilise ces listes dans la déclaration des "hosts". Comme nous avons généralement les mêmes profiles de serveurs, la définition d'une liste de service par profile de serveur est très pratique.
J'ai tout de même laissé la possibilité de redéfinir au sein de chaque "host" les services qu'il contient de manière individuel.
Ensuite, pour la génération c'est pareil, je peux ne générer la conf que pour une partie des serveurs ou des services.
Grâce à cela, nous sommes passé de 10 000 lignes de conf à environ 2 000. Et encore, dans ces 2 000 lignes, il y en a une grande partie qui ne bougent jamais.
Je partage donc l'idée de reféfinir la configuration de Nagios si tu te lance dans un projet comme celui-ci et je pense qu'intégrer la notion de "profiles" serait une bonne chose.
Chose amusante, le générateur de configuration est lui aussi en python :)
[^] # Re: Vachement gore
Posté par Etienne Bagnoud (site web personnel) . Évalué à 0.
Aïe.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Vachement gore
Posté par lolop (site web personnel) . Évalué à 3.
A moins que tu n'aie un éditeur ad-hoc qui te fasse une interface graphique...
Perso, pour un fichier à éditer à la main, je préfère de loin des choses comme yaml, ou encore carrément des sources Python en mettant en place quelques classes de wrapping pour alléger la saisie.
M'enfin, les goûts et les couleurs.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Vachement gore
Posté par Florian . Évalué à 6.
J'avais aussi à l'idée de faire une interface graphique à mon outil qui aurait pu modifier le XML facilement. Encore une fois à l'époque c'était un choix pertinent.
En tout cas, on peut débattre très longtemps sur le choix d'un format de fichier, mais je préfère largement voir ça :
<host name="monserveur" services-list="unix-www" ip="X.X.X.X" />
Plutôt que ça :
define host {
address X.X.X.X
host_name monserveur
alias monserveur
use generic-host
}
Pas sûr qu'en YAML ça soit mieux.
Enfin je préfère le choix d'un fichier de conf sur fichier plutôt que d'une conf en base ou par du LDAP qui oblige à installer des outils tiers et à maintenir des services.
Le fichier, pour de la configuration, c'est bien. Ca se lit facilement, ça se modifie facilement, ça se partage facilement avec du NFS, ça se backup facilement.
[^] # Re: Vachement gore
Posté par lolop (site web personnel) . Évalué à 3.
Et en général ça donne, pour reprendre ton exemple:
Une définition de classe, du genre:
hosts_list = []
class Host(object) ;
....def __init__(self,name,services_list,ip) :
........# ...
........hosts_list.append(self)
(si c'est une config dans un outil que pour moi, ça va directement dans le fichier de config, si c'est destiné à être plus réutilisé, ça va dans un module importé au début du fichier de config).
Et après le fichier de config devient:
Host("monserveur", "unix-www", "X.X.X.X")
L'avantage que j'y vois, c'est que tu peux utiliser toutes les fonctionnalités de Python pour faciliter l'expression de la configuration et les contrôles. Tu peux définir des constantes globales (par exemple UNIX_WWW="unix-www") pour éviter les fautes de frappe, tu peux ajouter des méthodes, utiliser des listes, etc...
Si tu organise bien les outils, ça fait quelque chose de bien lisible, facile à maintenir, et versionnable.
Par exemple, si tu fairefaire des modèles réutilisables:
class ServicesSet(object) :...
servicemail = ServiceSet("imap","pop","simap","spop","smtp")
Host("monserveur,"servicemail,"X.X.X.X")
Ca a un inconvénient par rapport à XML: c'est pour Python et difficilement réutilisable si tu recodes ton application dans un autre langage. Encore que... rien n'empêche de réécrire un fichier XML à partir d'une telle description en Python.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Vachement gore
Posté par lolop (site web personnel) . Évalué à 2.
[*] https://linuxfr.org/comments/1089768.html#1089768
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Vachement gore
Posté par Philippe F (site web personnel) . Évalué à 3.
http://code.activestate.com/recipes/496746/
Pour moi les avantages sont les suivantes :
- je garde la distinction entre fichier de config contenant des données et fichier exécutable
- le format est super facile à faire évoluer
- c'est très facile à modifier même quand on est pas développeur.
[^] # Re: Vachement gore
Posté par Philippe F (site web personnel) . Évalué à 3.
http://code.activestate.com/recipes/364469/
[^] # Re: Vachement gore
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Et pas de base de données, a terme cela veut dire mélange des données et de la configuration et on accède à tout cela avec le même mot de passe. Déjà que Firefox me gonfle avec son SQLite !
L'idée du LDAP est plus séduisante mais par exemple, mes fichiers nagios sont versionnés via svn et mis sur le serveur via cfengine. Donc on pourrait avoir un backend ldap qui génère les fichiers nagios en asynchrone.
Le problème est de vouloir avoir des fichiers de conf "synchrone" qui deviennent donc des données et qu'ils ne deviennent vite modifiable que par des IHM graphique.
[^] # Re: Vachement gore
Posté par sobek . Évalué à 1.
Certe, les fichiers de configuration actuels de Nagios sont assez pénibles, notamment du fait de la mauvaise habitude qu'a Nagios de ne pas démarrer à la moindre faute de frappe plutôt que d'isoler l'élément fautif.
Mais cela est toujours plus simple à gérer qu'une configuration en base de donnée justement parce que tant la génération que la vérification sont scriptable, et parce qu'il est possible de mettre en place un suivi des modifications.
Gérant par ailleurs des annuaires LDAPs, on peut certe gérer les héritages, mais tant la gestion d'intégrité que la gestion de version sont assez vite pénible si l'on veut faire cela correctement, et au final pas plus complexe qu'un générateur de conf à partir de fichiers plats ;-).
Quand aux bases SQL, pitié !!!
Rien ne me gonfle plus que de devoir installer MySQL juste pour gérer 3 lignes de conf (parce que bon, pour les vraies données, quand on a pris gout à PostgreSQL, il n'y a pas photo (oui, je sais, encore 2h à tenir avant vendredi... ;-) )
[^] # Re: Vachement gore
Posté par zebra3 . Évalué à 5.
Hihihi, pour ça il y a :
$ nagios -v /etc/nagios/nagios.conf
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Vachement gore
Posté par sobek . Évalué à 1.
Je connais et j'utilise, mais je trouve que c'est tout sauf un modèle de souplesse.
En particulier, si pour une raison ou pour une autre le service redémarre avant que tu n'ais stabilisé la conf, tu peux dire au revoir à la totalité de ta supervision, et pas seulement à la partie que tu étais en train de mettre à jour. Certe, cela ne devrait pas arriver, mais entre la théorie et la pratique...
[^] # Re: Vachement gore
Posté par zebra3 . Évalué à 3.
Après je pense qu'il faut être un peu rigoureux, et par exemple ne pas modifier la configuration en production : idéalement, il faut dupliquer la configuration dans /etc/nagios.test par exemple, et tester celle-ci. Une fois qu'elle est OK, il suffit d'un rsync pour l'appliquer et c'est terminé.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Vachement gore
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
C'est ce que je souhaites faire dès que j'ai le temps.
Le problème est de vouloir avoir des fichiers de conf "synchrone" qui deviennent donc des données et qu'ils ne deviennent vite modifiable que par des IHM graphique.
Il y a ldapvi. Tu vois ton arbres ldap comme un grand fichier ldif et tu l'édites avec vi.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Vachement gore
Posté par Jean Gabes (site web personnel) . Évalué à 2.
[^] # Re: Vachement gore
Posté par morphalus . Évalué à 2.
[^] # Re: Vachement gore
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
Excuse moi, mais je ne vois pas l'avantage par rapport a la configuration "native": nagios te permet de le faire directement, certes dans l'autre sens (déclarer des services pour une liste de hosts) mais le résultat est le même.
[^] # Re: Vachement gore
Posté par Jean Gabes (site web personnel) . Évalué à 1.
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 :)
# Enfin !
Posté par vjm . Évalué à 2.
Le fait de conserver la compatibilité avec Nagios pour la configuration et les checks n'est pas optimal (la configuration mériterait d'avoir une syntaxe plus claire, de pouvoir être générée à partir d'autres sources comme des inventaires sous forme d'annuaire ou de base de données ; certains checks mériteraient d'être intégrés au moins pour les cas de figure les plus communs comme le SNMP, un peu à la manière de Cacti) mais c'est le choix gagnant vu la base installée.
En plus en Python ! Si tu persistes, j'aurai très envie d'y contribuer.
[^] # Re: Enfin !
Posté par Jean Gabes (site web personnel) . Évalué à 3.
[^] # Re: Enfin !
Posté par Jean . Évalué à 2.
[^] # Re: Enfin !
Posté par Jean Gabes (site web personnel) . Évalué à 5.
# Tentative de réponse à la question
Posté par Flyinva . Évalué à 1.
Remplacer C par Python, outch, tu bouscules les « core » développeurs là ;-) Si des idées de shinken pouvait être intégrées dans une future version, ce serait déjà pas mal, quel que soit le langage. L'utilisation massive de fichiers texte pour communiquer entre les différentes parties de nagios®, c'est robuste, pratique mais en 2009, on doit pouvoir faire mieux.
Nagios® a déjà connu un fork : inciga. Nagios® XI™ sent le propriétaire. Ethan est absent des listes de diffusion. Tout cela n'est pas très réjouissant pour la communauté nagios® :-(
Pour finir, la réponse à la question sera très probablement : non.
[^] # Re: Tentative de réponse à la question
Posté par Jean Gabes (site web personnel) . Évalué à 2.
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.
# réimplementation?
Posté par nomorsad . Évalué à 0.
Par contre, tous les défauts de Nagios, en terme de performances, de modularité et de gestion de configuration sont justifiés, mais remettent en cause l'architecture complète de Nagios.
Et je ne parle pas même des rustines comme Centron&Co pour arriver à faire ce qu'un produit comme Nagios devrait savoir faire à la base.
Je trouve qu'il faudrait plutôt représenter cela comme un nouveau concurrent, qui en reprendrait les qualités de Nagios sans les défauts. Rien n'empecherait d'ailleurs les dev Nagios de collaborer au deux. C'est le libre quoi!
Quant au choix du Python, je pense qu'il est discutable, même s'il est évident qu'il faut un langage du XXIe siècle (indépendance OS, gestion mémoire, orientation objet, modularité, etc...).
[^] # Re: réimplementation?
Posté par Psychofox (Mastodon) . Évalué à 3.
Tout ce qui fait qu'une migration vers une solution de monitoring concurrente est difficile dans une entreprise, c'est quand des plugins doivent être réécris ou adaptés, que des access lists pour accéder à différentes machines sur le réseau doivent être modifiées, etc...hors la ça ne semble pas être le cas.
Un projet à suivre, et à faire vivre donc.
Question à l'auteur ? puisque les devs originaux sont peu perméables à vos propositions, un rapprochement avec d'autres acteurs comme op5 (les auteurs de merlin et ninja) ou icinga ne serait-il pas plus productif ?
[^] # Re: réimplementation?
Posté par Jean Gabes (site web personnel) . Évalué à 2.
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.
# Dommage
Posté par barmic . Évalué à 1.
Mais je ne vois vraiment pas ce qui empêche l'intégration de ton projet et d'implémenter chaque fonctionnalité en C. Ça permettrait :
d'avoir des changements petits et régulier plutôt que gros et en une fois
valider point par point et dans l'ordre chacune de tes idées
ne pas faire peur aux développeurs qui sont habitués à nagios et au C
En tout cas je te souhaite tout le courage du monde pour la partie politique qui semble s'annoncer plus compliquée que la partie technique (et c'est dommage).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Dommage
Posté par lasher . Évalué à 4.
[^] # Re: Dommage
Posté par Jean Gabes (site web personnel) . Évalué à 3.
[^] # Re: Dommage
Posté par lasher . Évalué à 2.
[^] # Re: Dommage
Posté par Psychofox (Mastodon) . Évalué à 3.
Moi je dirais qu'il faut être pragmatique, si on veut vraiment quelque chose, il faut savoir aussi se donner les moyens et passer outre une bête histoire de dépendance.
[^] # Re: Dommage
Posté par Jean Gabes (site web personnel) . Évalué à 2.
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.
[^] # Re: Dommage
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.