Nap's mini world

Elle est enfin là, et elle envoie déjà du gros

Bonjour,

La version 0.1 de Shinken est enfin arrivée

On va dire que c’est une bonne grosse 0.1 car mine de rien elle possède pas mal de fonctionnalités :

• prise en compte de la configuration de Nagios quasi complète
• reprise des sondes de supervisions et de notifications
• multiplateforme (testé sur GNU/Linux et Windows, mais doit fonctionner sans soucis partout où roule Python)
• hautement performant : j’en ai déjà parlé dans ces colonnes, enlever les erreurs de conception de Nagios, ça aide…
• architecture distribuée et hautement disponibles (bah oui, c’est un peu le but de l’outil hein…)
• modification à la volée des résultats en fonction de timeperiods
• configuration des escalades de notifications bien plus simple qu’avec Nagios
• UTF8 est géré (bah c’est du Python, je ne me suis pas foulé pour l’avoir hein…)
• un super logo (quoi? c’est une super fonctionnalité nan?)
• support des exports classiques (Mysql avec NDO et Merlin, Oracle avec NDO, Livestatus et même Couchdb )
• plein d’autres trucs qui vont me revenir une fois que j’airai publié ce post….

Les manques par rapport à Nagios existent, mais ne sont pas loquant pour la quasi totalité des utilisateurs :

• manque les / N de saut de jours pour les timeperiods (mais bon, Shinken a les exclusions de timeriods LUI, même si je comprends pourquoi ce n’est toujours pas OK dans Nagios..)
• pas de variables d’environnements _NAGIOS* lors du lancement des sondes (c’est un oubli tout simplement car je n’utilise pas cette fonctionnalité chez moi), mais peu de sondes l’utilisent de toute manière
• pas de commandes de types OCSP : dans Nagios elles ne servent qu’à la partie distribuée, donc bon…
• 10 ans de tests de l’application derrière elle… bon ça je ne vais pas le régler du jour au lendemain je crois…

Mais comment on la teste?

Le code est dispo sur le site officiel du projet : http://www.shinken-monitoring.org. Outre le classique tarball installable très facilement (Python + Pyro en apt-get et hop, c’est parti ), j’ai tout prévu pour les feignants (qui à dit “administrateurs efficaces”?) : une VM toute prête à être lancée est disponbile sur le site. Elle est importable sous VirtualBox et VMWare.

Mais comment on peut tester facilement un service daemon? Bah avec les interfaces wbe préinstallé pardi

Elles sont au nombre de deux : Ninja et Thruk. Elle s’accèdent facilement avec un http://IPDELAVM/ (connectez vous avec le compte shinken/shinken, puis faites ifconfig pour voir votre IP, et enfin lancez ./launch_all.sh pour lancer Shinken et Thruk).

Bref, aucune excuse pour ne pas tester. La configuration en place est un exemple de distribuée et hautement disponible : deux ordonnanceurs actifs et un en spare. De quoi killer du process sans peur

Le fichier README_FIRST.txt vous aidera d’ailleurs lors de ces tests en proposant des kill et moyens de vérifier que ça tourne toujours.

Et ensuite? Seedcamp!

Ok, la 0.1 est sortie, elle est chaude, possède sûrement un ou deux bugs, mais après, il se passe quoi? Et bien vous serez ravi d’aprendre que Nagios lance seedcamp, un concours pour des propositions d’amélirations de Nagios ou d’addons. La description complète est dispo sur le site de Nagios. Et bien vous avez devinez, Shinken va participer! Il est lancé demain 1er juin. Shinken compte bien être le premier projet proposé

Outre le fait que ça me fait bien marrer de participer (en plus si je gagne, ça me financera assez pour aller présenter Shinken un peu partout), c’est l’occasion rêvée de voir un peu comment est vu Shinken par rapport au Nagios Corporate : les participants sont évalués par la communauté. Bien entendu, si vous liez en bas le réglement de seedcamp, il y a des possibilité d’exclusions pour les projets farfelus. Je pense (espère) que Shinken ne rentre pas là dedans. Je pense donc que Shinken sera évalué de manière pertinente par celle à qui il est destiné : la communauté Nagios.

Si exclu?

Et s’il est exclu? Bah là le message sera clair : les possibilités d’inclusions dans le projet officiel Nagios sont morts. Shinken sera dès à présents libres (enfin encore plus que maintenant) par rapport au projet Nagios. La compatibilité des interfaces, sondes et configurations seront conservées, mais il n’y aura plus aucune retenue quand à rajouter des modules qui sont trop inovants par rapport à Nagios (comme un module de configuration en base par exemple).

Si écrasé?

S’il ne gagne pas et fait un score minable? Bah je me retire au tîbet… nan je blague, fait trop froid pour moi là bas. Mais je continuerai à l’améliorer jusqu’à ce qu’il remporte les suffrages de la communauté Nagios je pense.

Et si c’est le champion?

S’il gagne haut la main? Là, ça va être drôle. Le fait de revenir sur le choix du Python sera un niet ferme s’il n’est pas motivé techniquement, et puis bon le C c’est bien dans un noyau, mais en dehors faut vraiment en avoir besoin hein… Ceci dépendra des conditions d’inclusion de Shinken dans Nagios en fait.

Les vraies chances de réussites

En fait au vu de l’histoire récente, je serai le premier étonné de la victoire de Shinken. Pas pour ses qualités techniques ou ses nouvelles possibiltiés d’architecture. En elles j’ai toute confiance. Non, c’est sur le plan humain que je pense que c’est difficile : Ethan n’a jamais pris officiellement position sur Shinken, même en privé. Une exclusion de seedcamp m’effrai un peu, mais au moins on y verra plus clair.

Mais qui sait, la réunification tant attendue est peu être au bout du chemin, en tout cas, le proposition va être faite, on sera vite fixé.

Et ensuite seedcamp?

Peu importe seedcamp et ses résultats, de nombreuses choses sont encore en cours pour Shinken. Si d’ailleurs vous souhaitez filez un coup de main, c’est sans aucun problème

La roadmap/ticket tracking est là pour ça sur source forge.

Bon test de cette première version. dites moi un peu ce que vous en pensez, ainsi que du tout nouveau site de Shinken d’ailleurs

Un exemple de hack rapide

Dans un précédent post, j’ai déjà parlé des méthodes de développement que j’ai utilisé dans Shinken. Tout ceci a pour but de faciliter le développement par la suite, comme le rajout facile d’une propriété sans avoir à se soucier des héritages, distributions sur les différents éléments de l’architecture, etc etc.

Nous allons en voir un exemple avec un cas simple : le rajout d’un paramètre pour l’historique du flapping dans Shinken. En effet, Nagios et Shinken sont capables de détecter un élément qui fait le “yoyo” entre deux états. Plutôt que de spammer les users avec des notifications UP/DOWN/UP/DOWN, les schedulers sont assez malin (entendez utilisent un bête algorithme) pour s’apercevoir que l’état à changé X% de fois au cours des N derniers tests. La valeur X était déjà paramétrable pour les hôtes et les services, mais celle de N était hardcodée à 20 états.

Le problème c’est que 20 états ce n’est pas assez pour détecter un yoyo sur toute la nuit. Il arrive donc souvent des cas où l’on est averti pour rien, juste car on ne peux pas augmenter cette valeur. C’est dommage

Et bien plus maintenant !

Je l’ai rajouté dans Shinken en quelques lignes qui vont vous monter à quel point c’est simple d’aller hacker dans ce code, 5 lignes seulement dans notre cas

La modification

Tout se joue dans deux fichiers sources :

• config.py : qui gère les paramètres de configurations globaux
• schedulingitem.py : qui gère les algorithmes d’ordonnancement, des demandes de checks et autres.

Dans le premier (config.py) on remarque un tableau nommé properties vers le début du fichier avec toutes les propriétés possibles pour le fichier principal (nagios.cfg). Qu’à cela ne tienne, on va rajouter notre nouvelle propriété :

‘flap_history’ : {’required’:False, ‘default’:'20′, ‘pythonize’: to_int, ‘class_inherit’ : [(Host, None), (Service, None)]},

On rajoute donc le paramètre flap_history, qui n’est pas obligatoire (required=False), vaut par défaut 20, se transforme en objet int depuis la lecture de la chaîne de caractère dans le fichier, et va être présentée aux classes Host et Service avec ce même nom de flap_history (rôle de None, expliqué un peu plus haut dans le code, si vous mettez un nouveau nom, c’est lui qui sera utilisé pour cette classe).

Et voila, c’est tout pour la configuration ! Et oui, rien de plus. L’Arbiter va lire la configuration, transformer en entier la valeur, mettre 20 si elle est absente et va la fournir aux configurations envoyées aux schedulers automatiquement ! Là, ne pas hacker un tel code, c’est plus que de la fainéantise

On a réglé le problème de la configuration, maintenant on va utiliser notre nouvelle propriété. Ceci se passe dans deux fonctions du fichier schedulingitem.py : add_flapping_change et update_flapping. La première rajoute le changement d’état sur la pile de 20 éléments et s’assure que la pile fait toujours au plus 20 éléments. La seconde fait le calcul de pourcentage de changement à proprement parlé.

Les schedulingitems sont les hosts/services (une classe commune pour factoriser le code), et l’objet est nommé self en Python. On a dit que la propriété a été envoyée sur les classes Host et Service car c’est un paramètre global à tous les hôtes et services, pas la peine de le multiplier par le nombre d’hôtes et services. En Python, pour accéder à sa classe (qui est un objet comme un autre), il suffit de faire :

self.__class__

Donc là pour obtenir notre valeur, il suffit de faire :

flap_history = self.__class__.flap_history

On remplace les trois occurrences de 20 qui trainent dans le code par flap_history et c’est réglé, on peut tester/commiter :

if len(self.flapping_changes) > flap_history:

r += i*(1.2-0.8)/flap_history + 0.8

r = r / flap_history

Au final

Nous avons vu la définition et l’utilisation d’un paramètre global dans Shinken. C’est très simple, et il ne faut pas se priver Nous verrons une autre fois le rajout d’un paramétrage dans un service ou un hôte, c’est encore plus simple qu’ici car il n’y a pas besoin de passer par l’accrochage dans les classes Host et Service. Mais ce sera pour une prochaine fois, j’ai un git push à faire.

Si vous souhaitez hacker vous aussi, n’hésitez pas :

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

J’accepte volontiers les patchs

Juste pour info, dans le code de Nagios, si on voulait faire la même chose, il faudrait changer la macro MAX_STATE_HISTORY_ENTRIES en simple variable :

grep -r MAX_STATE_HISTORY_ENTRIES * | wc -l
30

30 lignes au minimum juste pour la partie traitement! Je n’ose même pas regarder combien de lignes ceci va coûter pour la configuration, mais bien plus d’une, ça c’est sûr…

Notez bien que je ne dis pas ça pour me moquer des développeurs de Nagios, comme quoi le code est imbitable non, car je n’aurais sûrement pas fait mieux en C.  C’est juste pour illustrer que parfois, utiliser des techniques de développements avancées (le développement dynamique qui a un peu irrité lors de l’annonce de Shinken sur la mailing list), ça ne fait pas de mal à l’efficacité…

Découpage organisationnel/technique

Dans l’Architecture de Shinken, un point important concerne les Realms (royaumes) qui servent à découper dans pans entiers d’infrastructure, comme un site distant par exemple, ou bien un client pour une entreprise qui propose une prestation de supervision.

Ce découpage est donc soit organisationnel, soit technique. Mais pour ce dernier, le choix du découpage se fait sur des critères géographiques, en terme de réseau principalement (pour ne pas avoir de fréquentes communications inter-continents par exemple).

Shinken fonctionne sur Windows (avec des services et tout et tout), et il est donc tentant de placer un poller sur un tel OS afin de lancer directement ses checks depuis une machine (et un compte de domaine) qui a les droits sur les autres machines, pour faire du WMI par exemple.

Mais comment faire en sorte que les commandes pour Windows partent sur ces pollers “Windows” et pas les classiques pollers “Linux”? On peut se dire que l’on utilise les realms, mais ce n’est pas une bonne idée en fait. Les realms sont des cloisonnements, il n’y a pas d’échange entre les schedulers (même au sein d’un realm d’ailleurs). Donc si un administrateur défini un Realm Linux et un Realm Windows, il va pouvoir obtenir l’effet souhaité (des commandes qui vont sur les bons pollers), mais à un prix énorme : plus de liens (dépendances) entre les hôtes Linux et Windows…

Cloisonnement technique

C’est pour cela que dans un même realm, il doit être possible de cloisonner “techniquement” les commandes sur des pollers. Ce cloisonnement, qui va être optionnel bien sûr, se fera dans la configuration avec une nouvelle option : poller_tag. Comme son nom l’indique, un poller va avoir un ou plusieurs tags, et les checks vont pouvoir également être taggués.

Si le tag au niveau des pollers est simple, se pose la question du tag des commandes : à quel niveau doit-on tagguer? commands, services, hosts? Et pourquoi pas les 3 finalement? L’héritage serait host->service->commands.

Le tag des commands est simple : une commande définie comme un exe au sens windows (PE et non pas ELF) sera naturellement tagguée “windows-poller”. Les tags au niveau service/hosts seraient un peu comme un “mini-realm” : au lieu de définir un realm complet (avec un couple scheduler/poller) pour une DMZ par exemple, il peut être pratique de juste dédier un poller (ou deux) dans cet environnement, et de tagguer les hôtes/services.

Un mini-realm?

Ceci n’est pas complètement orthogonal aux realms je l’admets, mais c’est plus une réponse aux “proxy nrpe windows” qu’à un réel besoin organisationnel que proposent les Realms.

Au passage, cette implémentation va être un bon exemple de “Hack” possible de Shinken. Je vais essayer de noter/expliquer l’implémentation dans un document afin de montrer que développer pour Shinken n’est pas complexe, loin de là