Retour des RMLL

Posted in Nagios, Shinken by Nap on July 12, 2010 6 Comments

Ça y est, les RMLL sont finis, et ont été plutôt intenses :)

Mine de rien, on a bien avancé avec monitoring-fr, on a monté l’association, on n’a pas trop trollé (un peu tout de même hein), et on a bien échangé sur la supervision et comment bien abordé certaines difficultés.

Concernant la conférence, les slides sont dispo sur le site des RMLL : http://2010.rmll.info/IMG/pdf/RMLL2010-AdminSys-SupervisionGrandsEnvironnements.pdf

Grande victoire sur moi même : je ne me suis pas écroulé devant le public. Si certains m’ont trouvé un peu “direct” dans certains réponses, c’est tout simplement car il n’est pas naturel pour moi de monter sur une estrade et que le stress me faisais répondre un peu vite tout simplement, donc désolé si ça en a choqué quelques uns :-? (la prochaine fois je prends quelques bières avant, promis).

J’espère que malgré cela la conférence aura plus (et il me semble que ça a été le cas pour beaucoup). Pour ceux qui l’ont ratée, le montage de la vidéo de la conf est en cours par l’équipe de monitoring-fr.org, je ne manquerai pas de prévenir une fois qu’elle sera dispo en ligne :mrgreen:

J’espère qu’elle fera réagir l’auteur de Nagios dans le bon sens, il est encore temps de se mettre à travailler ensemble. En tout cas, le projet avance, il semble plaire à beaucoup de monde. J’ai ainsi pu rencontrer l’équipe de Fusion Inventory lors des RMLL et il semble que nos projets soient amené à coopérer fortement dans l’avenir ;-)

Je remercie les autres membres de la communauté monitoring-fr ainsi que tous ceux qui sont venus nous faire un petit coucou (il fallait réussir à trouver le site des associations hein…), toutes les idées récupérées sur le stand ne seront pas oubliées comme la catégorisation des alertes ou bien l’importance de la notion problèmes/incidents. La fin de l’année sera animée pour Shinken et ses futurs utilisateurs, et un peu de mouvement dans la monde de la supervision, ça ne fait pas de mal :lol:

Retour à l’école

Posted in Nagios, Shinken by Nap on June 9, 2010

Et oui, je retourne à mon ancienne école, mais ce coup-ci, je serai sur l’estrade :mrgreen:

Je vais donner une conférence aux RMLL 2010 sur “Nagios et la gestion des grands environnements”. Et ça tombe bien, les conférences se passent à l’ENSEIRB, mon ancienne école :-)

Je vais donc aborder Nagios, mais pas que. après une petite présentation rapide de Nagios, et une démystification de ce qu’il est, je vais attaquer avec du gros, du bien costaux : la gestion de la configuration et ses techniques d’héritages. Après avoir perdu près de la moitié de la salle, j’attaquerai là où ça va faire un peu plus mal pour Nagios : les environnements distribués (et/ou hautement disponible). Je vais évoquer les solutions DNX, NDO et Centreon.

Après je vais parler un peu de Shinken, qui se propose d’être la solution à tout ça bien sûr :)

Je ne pourrai pas éviter de parler de l’état actuel du projet Nagios, et d’où il se dirige (le mur…). Je vais essayer de rester le plus objectif possible. A la fin, je ferai conf commune avec la communauté monitoring-fr pour montrer un peu sa nouvelle orientation ;-)

J’espère que cette conférence sera sympas à suivre, je vais tout faire pour en tout cas. J’espère y voir beaucoup de monde. C’est le Mercredi 7 Juillet à 17h à Talence.

Si au hasard il y a des points particuliers que vous souhaiteriez dedans, c’est le moment :) (oui faut vraiment que je finisse mes slides là..)

Shinken : example de Hack rapide du code

Posted in Programmation, Shinken by Nap on May 5, 2010

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 :cry:

Et bien plus maintenant :mrgreen: !

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 :-D

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 :lol:

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 8-) :

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é…

Shinken : tagguez vos pollers

Posted in Shinken by Nap on May 5, 2010

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à :)

Nagios : de l’open source à l’open core ?

Posted in Nagios by Nap on April 20, 2010 8 Comments

L’open core : Community/Enterprise

Je viens de tomber sur deux posts intéressants ici et qui traitent d’un problème qui se répand de plus en plus dans les logiciels ouverts touchant au monde de l’administration et supervision système : le modèle Community/Enterprise, déjà utilisé par Zenoss par exemple. Ce modèle à un nom en fait : open core.

Le principe est simple : une version open source, nommée Community, est fournie. Une version Enterprise, privatrice, est également présente et est la seule version supportée par la société éditrice du logiciel . Cette version possède des fonctionnalités bien plus avancées que la Community. Il est dit qu’au bout d’un moment, les avancées de la version Enterprise sont avantageux pour la community. Mais on peut se demander si ce n’est pas exactement l’inverse qui est plus réaliste.

Si l’on regarde un peu les versions Community de logiciels utilisant déjà ce principes, on s’aperçoit qu’un risque majeur les touchent déjà : le seuil de fonctionnalités. Comme va l’évoquer notre très cher JP Troll dans un de ses futurs articles (scoop inside  :mrgreen: ), ceci consiste à limiter le nombre de fonctionnalités que l’on fait entrer dans la version communautaire pour toujours garder un avantage certain à la version Enterprise.

Prenons deux exemples déjà utilisé dans un des deux articles cités : Zenoss et Hyperic-hq dans leurs versions communautaires. Les courbes ci-dessous sont la taille du code de ces versions fournies par ohloh.

Zenoss :

zenoss

Hyperic :

hyperic

On note un certain plafond, tout particulièrement pour Hyperic-hq. Les développeurs se sont endormis? Certainement pas. Mais pourquoi chercher à améliorer la version shareware de leur outils?

Oups, le terme est sorti. Shareware. Ne nous voilons pas la face, les versions communautaires y ressemblent fortement : limitées, elles demandent de passer à la version complète pour en profiter réellement. Au moins, ce n’est pas limité dans le temps, c’est déjà ça. De plus, il est toujours possible de forker, même si dans les faits, personne ne s’y attaque (vous avez vu un peu le nombre de lignes de code de ces outils? ;-)   ).

Mais ce modèle implique que les patchs proposés dans la version communautaire soient “laissés” à l’éditeur pour qu’il puisse les intégrer à la version privatrice.

Et Nagios ?

Mais alors où est le rapport avec Nagios finalement? Regardons un peu sa courbe de développement :

nagios-codehistory

Vous allez me dire que c’est une habitude chez Ethan (l’auteur principal de Nagios) d’avoir un tel fonctionnement, ce qui est particulièrement compréhensible après tout et l’on n’a rien à y redire. Mais regardons un peu ce qu’il a annoncé sur la mailing list :

“There is nothing broken or wrong with Nagios Core the way it is.”

Ah.. bah rangez vos patchs, la courbe va rester plate un moment alors… Mais pourquoi refuser toute avancées majeure? Nagios XI tout simplement? (pour rappel, Nagios XI est une solution privatrice basée sur Nagios éditée par Nagios Enterprise).

Après tout nous avons également “Our commercial Nagios XI solution is not 100% Open Source, and it probably won’t ever be in its entirety. [...] Most all other commercial Nagios solutions out there go the same route.” et “commercialization of Nagios is going to expand in the future, so we can continue to provide more great solutions for the people that need them.”

Le modèle “open core” est assez bien annoncé lorsque l’on met tout bout à bout. Procès d’intentions? Je pense que l’on a assez d’éléments pour dire que non.

Modèle efficace dans le cas de Nagios?

Outre le fait qu’un modèle purement open source (et non logiciel libre), et a fortiori open core, n’est pas efficace (cf article sur l’art de la guerre), on peut se poser la question si l’open core va bien fonctionner dans le cas de Nagios.

Pas si sûr. Contrairement à Zenoss et Hyperic, le code de Nagios est à tous ses auteurs respectifs, donc impossible de changer ou rajouter un licence. La solution XI ne peux pas rajouter un broker fermé il me semble, vu qu’il se charge dans un code GPLv2 (je peux me tromper sur ce point). Donc au pire, c’est le contour de la solution qui va être fermé. On a d’ailleurs eu une reprise en main de NDO, ce n’est pas pour en rajouter un autre, mais bien l’utiliser comme base, même si le schémas de la base justement est critiquable.

Contrairement à Zenoss et Hyperic encore une fois, l’offre “Enterprise” a mis du temps à se lancer. Des solutions alternatives existent déjà, et sont de très bonnes qualités (Centreon, Op5 Monitor 5). Pour Op5, un des développeurs principal de Nagios est même de la partie, avec son couple Merlin/Ninja.

Pour avoir un vrai modèle open core efficace, Nagios Enterprise a raté le coche. Il ne peut pas “boucler” des points clés de l’outil pour saper la concurrence, et arrive même après elle. Son auteur y pensait peut être depuis le début, mais il aurait du faire comme les autres dès ce moment là.  Maintenant au milieu du guet, on va juste avoir une dispersion des solutions. Toute basées sur le même cœur oui, mais solutions qui vont devenir (ou sont même déjà) incompatibles entre elles. Centreon va lancer son propre broker (dont les fonctionnalités font saliver d’avance :) ), Op5 lui part sur Merlin, et Nagios XI reste semble-t-il en NDO. Heureusement pour les utilisateurs, Centreon et Op5 semblent se mettre d’accord sur un modèle de base commun, ce qui est particulièrement bien pensé.

Ne nous voilons pas la face, la véritable intelligence ne va plus être dans le cœur de Nagios, mais bien dans ses solutions externes. Il va rester l’ordonnanceur central avec ses petits défauts de conceptions qu’on lui connait pour les environnements distribués, mais les corrélations, la notion d’évènement et les analyses vont se faire au niveau d’au dessus. Et tant mieux après tout, ce n’est pas à un ordonnanceur de gérer cela.

Je reste persuadé que lorsque l’on parle d’outils de supervision, l’apport de la communauté est indispensable. De plus, aucune entreprise, même de taille moyenne,  ne se lancerait dans un projet de supervision sans support et surtout sans intégration. Les licences ne sont qu’un facteur limitant (le nombre de machines explosent dans les datacenters, une solution sans licence à l’agent est nettement avantagée). Nagiox XI a un intérêt, c’est l’éditeur lui même. Mais le code de Nagios n’évolue plus trop, donc l’intérêt de ce choix est limité pour les utilisateurs.

Ethan avait-il seulement le choix de partir sûr cette solution? Si l’on reste pragmatique, je ne pense pas. Même en partant d’une solution libre (pardon, open source) qui existait déjà, il perdait sa légitimité d’auteur principal (du cœur oui, de la solution non), véritable argument marketing. Monter sa propre solution avec seulement des briques libres prends plus de temps qu’en faisant des concessions privatrices. Simple problématique de time to market finalement.

Est-ce dommageable ?

Dans les faits, le seuil de fonctionnalités est déjà présent depuis un moment pour le cœur Nagios. On n’a donc pas à avoir peur de l’avenir, on y est déjà.

Heureusement, les moyens de “bloquages” d’avancées en open source ne sont pas totalement actifs, en tout cas pour les solutions. Le cœur? Il va rester ce qu’il est, un très bon ordonnanceur. Tout le monde va sortir l’intelligence de l’outil. Question de modularité après tout. La phase de transition va être pénible, mais le temps que l’utilisateur a toujours une solution libre à sa disposition, ceci reste acceptable.

Nagios ne sera jamais totalement comme Zenoss finalement, et tant mieux. Il va aller vers autre chose. Il faut juste attendre vers quoi. Ou bien amorcer soit même la transformation en regardant ce qui est le plus propice à l’instant t pour arriver à une situation qui nous est avantagée, car il parait que c’est ce qu’il y a le plus efficace ;-)

Ceci va également être l’occasion de voir un peu l’affrontement des modèles open source et open core. Cette année va décidément être marrante :)

Shinken : le dispatching des configurations et les spares

Posted in Nagios by Nap on October 23, 2009 4 Comments

Rappel sur les daemons et les configurations

J’ai déjà évoqué le fait que Shinken utilise plusieurs daemons qui ont chacun leur rôle. Le maître de tous est l’Arbiter qui lit la conf, la découpe et l’envoie vers ses petits camarades. Bien sûr, les satellites comme les pollers ont besoin de connaître l’adresse des ordonnanceurs. Ces derniers ont la responsabilité de l’ordonnancement de la supervision. La perte d’un d’entre eux peu être embêtante : une partie des hôtes ne seront plus surveillés!

C’est pourquoi Shinken utilise un système de spare : des daemons seront lancés mais non actifs. Ils ne se verront affecter une configuration et donc une responsabilité que si un daemon maître meurt. Typiquement un placement de ces spares sur la machine de l’Arbiter peut être utile, il y a peu de chance qu’elle perde le lien avec elle même.

Regardons un peu le dispatching des configurations vers les ordonnanceurs et ce qui se passe lorsqu’un ordonnanceur n’est plus disponible

Dispatch des configurations

L’arbiter lit la configuration globale de l’administrateur, il la coupe en morceaux (autant que l’ordonnanceurs NON spare). Le dispatcheur (une Classe dans l’Arbiter), l’envoi vers les ordonnanceurs. Puis il créé une configuration particulière avec juste les adressess des ordonnanceurs à destinations des satellites comme les pollers ou le broker. Et hop, tout le monde est content.

Ca se résume en un diagramme:

shinken-conf-dispatching

Lorsqu’un ordonnanceur tombe

Personne n’est parfait, les OS non plus. Une machine ca peut tomber, un réseau aussi. Bref, les daemons ne seront pas toujours joignables. C’est pour cela qu’on peut définir des spare qui vont reprendre le flambeau des vérifications. Pour l’instant, seul les ordonnanceurs peuvent avoir un spare, mais ca ne devrait pas tarder pour les satellites car ce n’est pas bien différent.

L’Arbiter vérifie régulièrement que tout le monde est vivant. Si un ordonnanceur est déclaré mort alors qu’il avait la responsabilité d’une configuration, il envoie la configuration vers un spare disponible.Il met à jour les informations des satellites pour qu’ils prennent en compte cette nouvelle disposition.

Un cas intéressant arrive lorsque l’ordonnanceur n’était pas disponible à cause d’une perte réseau (vous savez, cette grande variable aléatoire :mrgreen: ). Il était encore vivant mais on ne le voyait plus c’est tout. Si la conf a été envoyé à un spare, on a un problème : deux ordonnanceurs avec la même conf. Pour l’instant il est demandé à l’ordonnanceur maître de gentiment arrêter son ordonnancement et d’attendre une nouvelle conf. Dans l’avenir, une solution plus élégante sera de demander plutôt au spare de lâcher la main, car il y a de fortes chances que ce dernier aient moins d’informations que le premier.

Ca se résume en un diagramme :

shinken-scheduler-lostEn bref

Imaginez un même système en C (juste le dispatching et la gestion des spares). … Ca y est vous le voyez? Compter le nombre de lignes que ca demande. … Combien alors? Tout ça? Maintenant regardons combien ce prends dans Shinken : dispatcher 200 lignes, satellitelink 100 lignes (et ca va fortement diminuer), satellite pour la gestion de la conf : 50 lignes. Ah oui,  le tout avec 30% de commentaires :-)

Le Python c’est bon.

Sortie de mon livre sur Nagios

Posted in Nagios by Nap on August 26, 2009

En octobre dernier j’ai entreprit d’écrire un livre sur Nagios. Après avoir écris plusieurs articles sur le sujet dans Linux Mag, il était temps de se lancer un nouveau défi. Je dois bien avouer que je suis particulièrement fier du résultat. Il est édité par Eyrolles dans la collection blanche. Ca tombe bien, c’est ma collection favorite (il n’y a qu’a regarder ma bibliothèque). Voici une petit photo de la couverture :

nagios3

Je n’ai pas été seul à travailler sur cet ouvrage. Je remercie encore chaleureusement ma femme Caroline pour ses diagrammes (je ne suis pas doué avec open office draw, elle oui :) ) et également Cedric Temple pour sa préface que j’apprécie énormément.

Le livre est découpé en trois grande partie:

L’aprentissage de la supervision/métrologie avec la théorie (et oui, il faut y passer!) et une première mise en place de Nagios.

Les techniques avancées de Nagios pour gérer les cas particuliers comme les Trap SNMP mais le tuning de Nagios ou la mise en place d’environnements distribués hautement disponibles.

Enfin, la dernière partie concerne l’écosystème de Nagios avec des outils indispensables comme Centreon ou Nagvis.

Ce livre a un but simple : faire le tour de la question Nagios. Une fois qu’un administrateur l’aura lu, il connaitra tous les principes et les astuces qui entourent Nagios et ses principaux outils (Centreon et NagVis). Il sera de même à gérer du début à la fin un projet de supervision/métrologie. En effet, l’accent est tout particulièrement mis sur l’aspect humain d’une telle entreprise. Faire accepter un util de supervision n’est pas aisé, même avec la meilleure volonté du monde. Ce livre donne toutes les informations pour déminer le terrain et permettre d’avoir un système informatique le plus efficace qu’il soit.

Au passage, c’est l’écriture de ce livre qui m’a permis de voir les plus gros points noirs de Nagios (oui, il en a quelques uns et je n’évite pas d’en parler dans le livre) et de les corriger. Par exemple, sans le chapitre 8 sur la gestion de configuration pour les grands environnements, le patch pour qu’un service appliqué sur un hôte passe devant le même service apliqué sur un groupe d’hôtes ne serait pas être jamais sorti ;)

Je continue bien sûr mon activité dans le monde Nagios avec comme point de mire les performances et les environnements distribués pour avoir un Nagios encore plus fort dans le monde de l’open source, et même au delà.

Patch Nagios pour une gestion plus fine de la configuration

Posted in Nagios by Nap on July 2, 2009

Lorsque l’on étudie un peu la gestion de configuration de Nagios, on est impressionné  par la richesses des possibilité, que ce soit sur les macros, les services appliqués sur les groupes, les exeptions, etc. En fait, une seule fonctionalité manque lorsque l’on souhaite gérer finement et effiacement sa configuration : les exeptions sur les services appliqués sur des groupes de noeuds.

Un tel service appliqué sur un groupe prenait systématiquement le pas sur le même service appliqué sur un noeud. On était obligé de contourner le problème avec la mise en place de MACROS spécifiques et de modifier les commandes. Ce n’est désormais plus nécessaire avec la nouvelle version de Nagios. J’ai proposé dernièrement un patch qui a été appliqué dans la 3.1.2.

Cette modification permet à un service appliqué sur un noeud de prendre le pas sur le service appliqué d’un groupe. Cette possibilité permet de définir très simplement une execptions d’un service, sans avoir à sortir un noeud d’un groupe et dupliquer tous les autres services qui y étaient acrochés.

Par exemple, avec la défiition suivante :

define service{
use     generic-service
hostgroup_name       all-server
service_description     service-test
check_command   check_ping
}

define service{
use     generic-s
ervice
host_name       srv-1
service_description     service-test
check_command   check_local_disk
}

Et bien maintenant c’est la seconde définition qui va gagner, ce qui est tout de même bien pratique :mrgreen:

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…

Next Page »