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 : la 0.1 est arrivée!

Posted in Shinken by Nap on May 31, 2010 3 Comments

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

Bonjour,

La version 0.1 de Shinken est enfin arrivée :mrgreen:

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 8-) )
  • 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… :lol:

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é :mrgreen:

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

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

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

Shinken : quelques news sur la prochaine 0.1

Posted in Shinken by Nap on April 26, 2010 2 Comments

Bonjour,

Ça fait quelques temps que je n’ai pas parlé de Shinken. Outre le fait que j’avais des articles à finir pour LinuxMag et autres (comme celui sur l’art de la guerre appliqué au logiciel libre), les points traités ces temps-ci sur le projet ne sont pas spectaculaires, mais pourtant importants.

Tout d’abord le projet a une véritable documentation. Celle-ci est basée sur le formidable travail de l’équipe monitoring-fr qui a transformé la documentation HTML de Nagios en DocBook. Ce format est en XML, mais il n’est pas si mal que ça. Il me rappelle un peu le LaTeX en fait. Un grand merci à l’équipe monitoring-fr pour ce travail titanesque. Celui-ci permet en effet d’automatiser des exports de la configurations dans différents formats. Les deux utilisés pour l’instant sont le PDF et le XHTML. Ce dernier est justement à jour sur le site du projet. Là encore, le style CSS utilisé est un mix entre le style utilisé par l’équipe monitoring-fr et celui du site de Shinken :mrgreen:

Dans la configuration sont présentes les informations pour configurer les satellites afin de monter une architecture distribuée hautement disponible. Une page a été rajoutée également par rapport à la documentation Nagios classique : une mise en place sur Windows ! Sur ce système, il est en effet possible (et même très simplement) de mettre en place Shinken en tant que Service Windows. Un cas particulier peu intéresser du monde : imaginez un daemon poller qui tourne avec un compte de domaine qui a le droit de faire des requêtes WMI sur les autres Windows du domaine? Plus besoin de monter une application pour faire un relai WMI, c’est natif avec Shinken 8-)

Je n’ai pas encore fait de tests de performances sur cet environnement, mais je ne m’attends pas à avoir 150000checks/5min comme sur un Linux car Windows est bien moins à l’aise lorsqu’il s’agit de lancer des processus. D’après ce que j’ai commencé à voir, un serveur devrait être largement suffisant pour une moyenne entreprise.

Pour la version 0.1, il ne reste plus grand chose en attende en fait. La documentation est perfectible, mais acceptable. Il y a encore un petit bug avec la gestion des Downtimes sur la partie Notifications, mais Gerhard est en train de l’éradiquer, encore merci à lui ;-)

Le site devrait bientôt avoir une petite animation sur le fonctionnement de Shinken par rapport à son architecture, mais je n’en dit pas plus, ceci sera une petite surprise pour la 0.1

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

Art of (free software) war

Posted in Général by Nap on April 18, 2010 9 Comments
Ce texte fait suite à la lecture de trois ouvrages : « Richard Stallman et la révolution du logiciel
libre », « L’art de la guerre » de Sun Tzu, et « Traité de l’efficacité » de François Jullien. Si le
premier est une oeuvre bien connue des acteurs du monde du libre, les deux dernières méritent
également d’être lues. L’art de la guerre est le grand classique sur la vision des affrontements du
point de vue chinois. Le second en est un approfondissement. Il présente les pensés occidentales et
orientales de l’efficacité de la guerre, mais aussi plus généralement de toute activité humaine. Ce
sont justement ces idées que je vais tenter d’appliquer au monde du libre. Je n’ai fait que tenter
d’appliquer ce qu’il explique si bien à notre environnement.

Lors de la lecture de la biographie de Richard Stallman sortie dernièrement (et dont je recommande chaudement la lecture), un chapitre m’a un peu interpellé : celui qui montre la différence entre le mouvement Open Source et celui du Logiciel Libre.

L’Open Source se concentre sur l’obtention de logiciels les plus performants et stables possibles. C’est une vue purement technique qui pense que la méthode de développement ouverte est la plus performante possible. Ils s’opposent ainsi aux logiciels privateurs en proposant des logiciels ouverts performants.

Le Logiciel Libre repose quant à lui sur la sauvegarde des libertés des utilisateurs. Le fait d’avoir des logiciels au code ouvert n’est qu’une nécessité pour arriver à ce but. Ce n’est pas l’objectif final. Sa principale méthode reste la persuasion sur l’importance de la sauvegarde des libertés. Il s’oppose également aux logiciels privateurs.

J’ai cherché à savoir lequel était le plus “efficace” dans cette guerre face aux logiciels privateurs. Pour cela, j’ai fais un parallèle entre ces deux protagonistes et les méthodes occidentale et chinoise de la stratégie. Les idées utilisées pour décrire l’efficacité de ces dernières sont celles de l’essai “Traité de l’efficacité” de François Jullien (disponible ).

Au final, on voit que le logiciel libre est plus efficace dans cette guerre que le mouvement open source. Ceux qui veulent savoir pourquoi peuvent accéder à cette étude sur ce lien : étude sur l’art de la guerre appliqué au logiciel libre. Une version PDF est également disponible là.

Déduplication : bloc fixe VS bloc variable

Posted in Programmation by Nap on March 14, 2010 7 Comments

Intérêt de la dé-duplication

J’ai testé il y a quelques temps le filesystem lessfs (site officiel du projet). C’est un filesystem très simple à mettre en place, de type Fuse (donc en user space) qui permet de monter un espace de dé-duplication à la volée.  Cette fonctionnalité permet de gagner une place considérable lorsque l’on a des données qui se ressemble fortement.

Elle est complémentaire de la compression. Là où vous aller gagner sur un fichier avec la compression, si vous en avez deux, vous aller stocker deux fois la taille compressée. Avec une passe de dé-duplication avant, vous n’aurez qu’une fois chaque bloc, puis vous pouvez compresser ce qui reste.

Deux méthodes : bloc de taille fixe ou variable

Taille fixe

Les blocs justement. Dans lessfs, ce sont des blocs de taille fixe. Donc on applique un algorithme très simple :

  • on coupe la donnée en bloc de NKo (prenons 4Ko)
  • on fait un hash de chaque bloc
  • si on a déjà un hash, on change le bloc par un simple pointeur vers le bloc déjà sauvegardé
  • sinon on sauvegarde le bloc et son hash

Simple. Efficace? Pas si sûr. Bien entendu, si vous faites une copie d’un fichier, celle-ci ne va quasiment rien vous coûter. Mais faire des copies intactes de vos fichiers arrive parfois avec des sauvegardes, et encore…

Taille variable

Si l’on veut être plus efficace, il faut faire une recherche dans les données d’un bloc déjà vu. Mais là où avant on cherchait avec un début de bloc tous les 4Ko, là on cherche pour tous les octets. En effet, si vos blocs ne sont pas parfaitement alignés, vous ne reconnaîtrez pas votre bloc, car il a pris un simple offset de quelques octets!

Bien sûr, ce genre de recherche est bien plus couteux en terme de CPU, 4K calculs fois plus. (En fait u peu moins, dès que vous raccrochez un wagon de blocs déjà connu, un seul calcul suffit).

Exemple de gain

Un exemple?

J’ai codé rapidement un petit script en Python qui réalise ces deux types de dé-duplications :

  • recherche des mêmes blocs de 4Ko avec recherche par fenêtre glissante
  • recherche brut de frondrie, bloc de 4k

Voici les résultats sur un répertoire plein de fichiers de type office and co:

****** Stats Varible: Deplicated 342756761/465877423 = 73.00% Dedup+compress 426510002 =91.00%
****** Stats Fix: Deplicated 59596755/465877423 = 12.00% Dedup+compress 68349038 =14.00%

On a donc 73% de gain avec des tailles de blocs variables, 91% si on les compresse par dessus. La méthode fixe bourrine n’arrive elle qu’à un faible 12%.

Bon bah il faut demander à lessfs d’appliquer cet algo? Pas si simple, de un c’est ultra consommateur en CPU, donc il faut le faire en post-process, pas à la volée. Et surtout l’algo utilisé semble avoir été breveté par EMC… Et après ça qu’on vienne encore me sortir que les brevets sont fait pour protéger l’innovation…. l’investissement oui, l’innovation non…

Pour ceux qui ont la chance de ne pas habiter dans ce merveilleux pays des brevets logiciels, vous pouvez tester le script.

La réponse de l’auteur de Nagios

Posted in Nagios by Nap on March 2, 2010 3 Comments

Ca y est, l’auteur de Nagios a répondu à la lettre ouverte sur la mailing list ici. Réponse assez complète, mieux que la blague qu’il nous a sorti sur “nagios-drama”. Voici ce que l’on peut retenir de sa réponse :

  1. il ne lâche pas la partie open source, les fond de XI permettrons de développer d’avantage la partie open source
  2. XI n’est pas open source car il utilise des modules externes qui ne le sont pas
  3. la commercialisation de Nagios va se développer
  4. la gestion du trademark ne sera pas assouplie
  5. c’est lui qui dirige depuis 11ans, ça ne va pas changer comme ça
  6. le core est bien comme il est, pas besoin de changements, ou alors dans les addons

Bon le point 1 tant mieux, reste à le voir en action. Pour XI ok, de toute manière c’est son application, il n’a pas à justifier son choix de licence après tout. On voit mieux comment ça va s’articuler avec le point 3 : on est bien parti pour avoir une version Enterprise complète (XI) et une communautaire. Ca ressemble bien à Zenoss pour çe point là, espérons que le développement de la partie open source n’est pâtira pas.

Le point 4 est ce qu’il est, même si il protège un peu trop son trademark en ce qui concerne l’affaire nagios-fr/icinga au point de jouer contre son camp. Le point 5 bah pas grand chose à dire.

Le point 6 lui est plus discutable. Je suis d’avis que ce n’est pas le core qui est bien, mais les idées qui propose (la gestion de la configuration, le support des sondes de checks et de notification) mais son implémentation le limite à des environnements de taille moyenne : les petits environnements tournent en général sous Windows, là où Nagios ne tourne pas, et les grands on besoin de bien plus de performances que Nagios propose pour l’instant, et surtout a besoin d’une centralisation de certaines choses comme les notifications et d’une supervision distribuée et hautement disponible.

Au moins on sait où on va maintenant avec Nagios, on a les grandes lignes, le virage de la phase business (open source : dev, communauté puis business) est amorcé. Espérons qu’on ne tombe pas dans le ravin.

Next Page »