URL: https://linuxfr.org/users/naparuba/journaux/nagios-va-t-il-quitter-le-c-pour-le-python Title: Nagios va-t-il quitter le C pour le Python? Authors: Jean Gabes Date: 2009年12月10日T15:57:39+01:00 Tags: Score: 23 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](http://www.nagios-fr.org/2009/12/shinken-nagios-core-killler)

AltStyle によって変換されたページ (->オリジナル) /