Shinken : Nagios Core killler ?

Posted by Olivier Jan on 7 Déc 2009 in Nagios Core, Planet | 0 comments

Une proposition étonnante a eu lieu sur la mailing list de développement de Nagios. Jean Gabès 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.

Partie comme 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é, à la grande surprise de l’auteur lui même, bien plus rapide que Nagios lui même.

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.

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.

Les idées issues de ce proof of concept ayant déjà été rejetées par les core développeurs ce Nagios car trop complexe à intégrer au cœur écrit en C, Jean a 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 légère 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 propositions sont restées timides et la plupart demandent encore des preuves sur les performances. Il sera intéressant de suivre leur réponses lorsqu’ils vont s’apercevoir que les gains sont réels.

À propos de l’auteur de Shinken

Jean Gabès a déjà par le passé vu accepter certains de ces patchs dans le Nagios Core dont le plus fameux est certainement l’algorithme de calcul et de validation de la configuration de Nagios. Il publie régulièrement des articles sur Nagios et la supervision Open Source dans Linux Mag et est également l’auteur du livre Nagios 3 pour la supervision et la métrologie.