Shinken : quand un python rencontre Nagios

Posted in Nagios by Nap on July 2, 2009

J’ai commencé voila quelques temps le projet Shinken. C’est une ré-implémentation de Nagios en Python qui va me permettre de maqueter certains principes pour Nagios avant de me les fader en C. C’est pour cela que j’ai choisi le langage Python qui est particulièrement élégant et jouissif. Si vous ne le connaissez pas, aller faire un petit tour sur http://www.python.org/ et laissez vous emporter par ce super langage.

Shinken est le résultat de mon étude de Nagios dont je parlerai un peu plus tard. Ce projet est déjà très efficace, mais j’étais persuadé que certains petits détails étaient encore améliorables. Par exemple, le lancement des sondes est ce qui coute le plus cher en terme de performance pour Nagios. Éviter de forker en ayant un pool de processus peut être bien plus intéressant. Ceci se code en quelques lignes de Python. De même, les aspects distribué de Nagios ne sont pas parfait. Les Nagios n’ont aucune connaissance des autres. Si avec des solutions comme Centreon il est facile de les gérer, certains problèmes persistent comme les notifications qui sont envoyées par chaque Nagios et ce séquentiellement.

L’intérêt de Shinken est de reprendre la configuration de Nagios ainsi que ses principes de supervision qui sont très pousés tout en proposant une novuelle architecture pour le programme à proprement parlé. Shinken est par exemple capable de couper automatiquement la configuration en partie totalement indépendantes qui vont pouvoir être, encore automatiquement, envoyées vers un scheduler qui va ordonnancer les vérifications et prendre les décisions en cas de problèmes.

Le nom du projet n’a pas été facile à trouver : je suis très long pour trouver des noms. Je peux dire merci à Wikipedia pour celui-là. je cherchai un nom de sabre japonais (j’aime bien la sonorité des noms japonais) et je suis tombé sur celui-là. Le sabre illustre la faculté de couper la charge automatiquement sur plusieurs machines. Et le Shinken est le sabre qui coupe le plus.

Le code est déjà bien avancé et est en licence AGPLv3.  Je reviendrai plus tard sur ce choix. Je suis en train de monter une première version sur sourceforge. Et plus important encore, le logo est déjà prêt :)

shinken

Merci à l’auteur cisoun pour sa mascotte ouaaargh qui a servi de base à ce logo :)

Pour ceux qui veulent voir un peu ce que cela donne, vous pouvez obtenir la dernière version du code avec git (paquet git-core sous debian):

git clone git://shinken.git.sourceforge.net/gitroot/shinken/shinken

Patch Nagios pour un démarrage (bien plus) rapide

Posted in Nagios by Nap on July 2, 2009

Il y a de cela un an, j’ai pris au mot l’auteur de Nagios lorsqu’il écrit dans la documentation de Nagios concernant les vérifications effectuées au démarrage :
“That means all you CompSci graduate students who have been emailing me about doing your thesis on Nagios can contribute some code back. :-)
Je ne sais pas qui ils sont, mais j’ai essayé de résoudre le problème poser : la vérification des liens de parentés dans Nagios était horriblement longue. En fait, j’ai même réussi.

Pour rappel, Nagios permet de définir pour un host un ou plusieurs parents (en terme de réseau). De cette manière, si un switch tombe par exemple et que l’administrateur a bien configuré ses serveurs pour qu’ils soient des fils du switch en question, il ne va recevoir qu’une seule alerte, celle du switch, plutôt que N alertes des serveurs. C’est la dépendance réseau. Cette relation forme un arbre : Nagios remonte les branches pour trouver la cause du problème. La racine est le noeud Nagios lui même. Mais que se passe-t-il si on autorise les cycles dans la configuration? Nagios va tourner en rond lors de la recherche de l’erreur! :evil:

Pour éviter cela, Nagios fait une vérification au démarrage afin de trouve les cycles dans cette configuration s’ils existent. Un premier algorithme naïf est en O(n²). Et bien dans Nagios arrivait à faire du O(n3)… Vous aller me dire que ce n’est pas si grave que ça. Et bien en fait si. Prenons une configuration “costaux” de 40000 hosts avec des relations de parentées. Et bien la vérification prends 70s sur un Core2 à 2.4Ghz. Ce n’est pas négligeable, car pendant ce temps, il n’y a pas de supervision…

J’ai donc décidé d’appliquer mes cours de théorie des graphes et de faire un simple parcours en profondeur, aussi nommé Deep First Search (DFS). C’est donc un algorithme récursif, ce qui n’a rien d’étonnant dans le monde des graphs :mrgreen:

Son fonctionnement est légèrement différent du DFS standard, car le but n’était pas de savoir si une boucle existait, mais de trouver TOUS les noeuds étant dans une boucle, afin d’aider l’utilisateur à corriger les problèmes en un passage.De plus, il n’y a pas de noeud root sur cet arbre de relation. On peut potentiellement partir en plein milieu de l’arbre, ce qui ne facilite pas les choses.

Les noeuds peuvent avoir plusieurs attributs :

DFS_UNCHECKED 0 valeur par défaut
DFS_TEMPORARY_CHECKED 1 a été parcouru une fois
DFS_OK 2 pas de problème
DFS_NEAR_LOOP 3 a des fils à problèmes
DFS_LOOP_INSIDE 4 fait parti d’une boucle

Nouveau test avec ce parcours en profondeur au lieu de l’algorithme initial : 0.006864 sec :-D

Après une longue période de non réponse de l’auteur de Nagios et le “coup de pied au cul” de Icinga avec leur tentative de Fork, de nouveaux développeurs ayant accès au CVS de Nagios ont été nommés. C’est ainsi que mon patch a été intégré dans la version 3.1.2 de Nagios et que des milliers d’administrateurs vont voir leur Nagios démarrer bien plus rapidement.

Reste à appliquer ce principes aux autres relations de dépendances dans Nagios…

« Previous Page