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

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

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.

Nagios : l’auteur tente de museler sa communauté pour cause d’avoir été trop libre!!

Posted in Nagios by Nap on February 23, 2010

C’est un cri d’alarme de la communauté Nagios que je me permets de relayer ici. En effet, après une longue phase d’ignorance de cette communauté de la part de l’auteur de l’outil, nous sommes arrivés à un point qui semble sans retour : l’auteur tente de museler la communauté française pour avoir été trop ouverte!!

Revenons un peu sur les faits : lancé il y a plus de 10ans, Nagios est encore à l’heure actuelle l’outil de référence dans le monde de la supervision open source, et de sérieux concurrents comme Zabbix ou Zenoss commencent à lui faire de l’ombre. Dans le domaine de l’open source, et tout particulièrement celui de la supervision, la force des outils reposent sur leur communauté. Celle de Nagios a été fleurissante pendant des années. Cependant, depuis environs deux ans, l’absence de réponse de l’auteur principal aux propositions de cette communauté a légitimement irrité cette communauté, au point de voir fleurir un fork il y a environs un an, nommé Icinga.

Là où l’histoire se complexifie se passe dans la sphère économique des sociétés utilisant et supportant Nagios. Comme pour beaucoup de logiciels commençant à prendre de l’ampleur, après plus de 8 années dédiées au projet l’auteur a légitimement crée une société de support et d’intégration nommée “Nagios Enterprise” et qui a déposé le nom “Nagios”. Le fork “Icinga” est issu de membres de la communauté Nagios qui sont employés par “Netways”, société allemande qui fait elle aussi du support et de l’intégration de Nagios. Si la licence GPLv2 est respectée, l’opportunisme et le manque de fair-play de cette société a fortement irritée l’auteur de Nagios et le reste de la communauté qui est restée fidèle dans sa grande majorité au projet initial.

Cette histoire semble avoir malheureusement eu un effet collatéral : l’auteur de Nagios s’est retourné contre sa communauté et l’ouverture qui a permis ce fork en l’ignorant encore davantage si c’était encore possible, en ne répondant pas par exemple à des propositions d’amélioration substantielles de code. Dernier affront en date et non des moindres : l’auteur demande à ce que lui soit cédé l’enregistrement DNS nagios-fr.org afin qu’il puisse réunir une communauté plus “corporate” car celle-ci a parlée sur son site du projet open source, mais félon à ses yeux, Icinga. Posts qui de plus n’étaient pas particulièrement élogieux. Fork qui au final aura plus coupé l’auteur de sa communauté que simplement un projet en deux.

La coupe est pleine pour la communauté qui se veut aussi ouverte que les outils qu’elle défend. Dans logiciel Open Source, il y “free as in beer” mais aussi “free as in speech”. Olivier Jan, fondateur et leader de cette communauté francophone, a ainsi répondu [1] qu’il ne serait pas possible de se laisser dicter ce sur quoi la communauté pouvait parler. Pour ne pas risquer une hypothétique assignation en justice (pour protection de trademark), il a donc été décidé d’obtempérer à l’attaque en déplaçant le site de la communauté vers monitoring-fr et de donner nagios-fr.org à la société Nagios Enterprise une fois la migration finie.

C’est donc avec une lettre ouverte [2] au titre de “The nagios community wants to keep its open soul” que la communauté demande où ce projet se dirige, s’il sera toujours ouvert et respectueux des principes même des l’open source. Des questions se posent en effet sur la réelle volonté de laisser ce projet open source en gelant la partie GPL et en l’incluant dans une solution fermée (”Nagios XI” éditée et diffusée sous peu par Nagios Enterprise) qui sera vraisemblablement seule à évoluer dans les années à venir. La communauté demande encore comment elle est perçue, si elle a encore sa place et si elle est tenue de tenir sa langue dans sa bouche sous peine de poursuite judiciaire en cas de non respect de la sacro sainte parole corporate de Nagios Enterprise.

Cette communauté fortement active ces dernières année est supportrice de l’industrialisation et le support de Nagios par des sociétés de logiciels libres, mais à la condition de pouvoir garder son âme. Nous souhaitons tous que Nagios conserve son rang qui ne l’oublions pas lui a été apporté grâce au soutient de toute sa communauté et que le projet revienne à la “bonne époque” où les codeurs et personnes de bonne volontés avaient encore leur mots à dire face à la communication marketing.

Espérons que cette lettre ne restera pas lettre morte, car ceci finirait de creuser le gouffre qui sépare l’auteur de Nagios et sa communauté qui est la vraie force motrice du projet et ferait le nid d’un fork qui diviserait encore la communauté, et qui rajouterai encore des noms tabous sur les sites traitant de Nagios.

Toutes les personnes souhaitant apporter leur soutient à notre démarche peux le faire en votant sur http://ideas.nagios.org/a/dtd/22035-3955 (pas besoin d’avoir un compte) qui est le site des idées de Nagios.

[1] : http://www.nagios-fr.org/2010/02/accuse-nagios-fr-org-levez-vous/
[2] : https://sourceforge.net/mailarchive/forum.php?thread_name=20100223103544.9upjoc1mbogwwc4o%40intra.expertise-online.net&forum_name=nagios-devel

EDIT: l’auteur a répondu. Voir pour sa réponse.

Shinken : quel avenir pour Nagios? Shinken?

Posted in Nagios by Nap on December 9, 2009 5 Comments

Certains ont du le remarquer : j’ai fait une proposition étonnante sur la mailing list de Nagios devel. Je ne propose rien de moins que de mettre Shinken comme branche développement de Nagios4 au lieu de l’ancienne implémentation C. Regardons un peu pourquoi je propose cela.

L’histoire récente de Nagios

Shinken est parti comme un proof of concept que j’utilisais pour démontre que mes idées pour Nagios n’étaient pas complètement absurdes. En effet, les patchs que j’ai proposés ont tous eu du mal à intégrer le core. Pourtant je les ait bien expliqué (enfin je crois), documenté et codé. Il est très simple de faire accepter un patch de correction dans Nagios, mais un patch d’amélioration de fonctionnement est bien plus long a intégrer. Pourquoi? Maitriser le cœur de Nagios n’est pas chose aisée, et je suis loin de connaître toutes ses subtilités malgré le temps que j’ai passé à le lire.

Jusqu’il y a quelques mois, Ethan était seul à accepter les patchs pour Nagios. Mes patchs ont étés magnifiquement ignorés à cette époque. Puis il y a eu l’histoire Icinga. Là Ethan a eu chaud, mais a bien réagit : il a ouvert l’accès au CVS à d’autres dev. Et hop, pleins de patchs on étés intégrés, dont les miens. Il y a eu aussi une ouverture de nagios ideas et cie. Très bien.

Et depuis? Bah Ethan se fait toujours aussi absent de la mailing list. Et qu’est ce qu’il nous sort? Nagios XI. C’est quoi cette bête? Et bien tout simplement une jolie couche graphique pour Nagios. Quel est l’intérêt face à des solutions comme Ninja ou même Centreon? Aucun. Un désavantage? C’est payant (quel bonheur de gérer des licences..) et non libre!!

Un Nagios a deux vitesses

On ne peux pas trop lui jeter la pierre, Ethan doit faire vivre sa société, et s’il décide de faire plus que du conseil/intégration et de vendre ses licenses on n’a pas à s’y opposer après tout, c’est son choix. Mais celui-ci implique que des parties des améliorations de Nagios ne seront plus open source. Il est prévu un module pour la supervision distribué… dans XI, pas dans le core. On voit poindre à l’horizon un Nagios a deux vitesses:

  • Nagios community : le Nagios open source que l’on a sous la main
  • Nagios Enterprise : le Nagios d’Ethan avec pleins de trucs géniaux, mais en close source et sous licence.

Bien d’autres font ça, Zenoss par exemple. Personnellement je ne suis pas un grand fan de ce modèle. Je n’aime pas gérer les licences, ça tombe toujours au mauvais moment ces trucs là. Je ne parle même pas de la communauté Nagios qui va fondre comme neige au soleil (vers Zabbix peut être?). Ce n’est pas acceptable.

Une stagnation dangereuse pour Nagios et une solution

Il faut un Nagios full open source qui évolue plus vite. Zenoss avance vite, Zabbix aussi, Nagios doit faire au moins aussi bien. Bien sûr il ne faut pas casser la compatibilité pour les users, c’est à dire la configuration. Mais le reste? L’administrateur s’en fiche bien que ce soit une implémentation ou une autre le temps que ça marche pareil (voir mieux…).

Les core dev ne sont pas fans des grands changement (purement technique) au sein du core. Leur réponse à un changement comme avoir un pool de process n’est pas ” c’est totalement débile comme idée”, mais “ça change trop de choses”. On peut alors légitimement se poser la question sur l’avenir de Nagios. Si les propositions inovantes ne sont pas retenues, même si elles sont pertinentes, c’est qu’il y a un problème.

Quel est-il ce problème justement? A mon avis, il vient de l’implémentation actuelle en C. J’aime le C, mais pas pour tout. Quoique l’on peut penser, un scheduler n’est pas un travail de bas niveau. Alors pourquoi Nagios est en C? Car il a plus de 10ans. A l’époque, les langages de plus haut niveaux n’avaient pas totalement fait leur preuve. De plus, je pense que c’est le langage préféré d’Ethan tout simplement. Cette implémentation est bien faite, mais avec du C point de miracle, c’est long à gérer et les possibilités d’erreurs sont multiples. Penser à un pool de process en C effraie, moi le premier. Mais c’est faisable en C avec pas mal d’efforts et de tests, Apache l’a bien fait. Mais dans les langages de plus haut niveaux, les Poll de threads ou de process sont livrés en standards, déjà débuggé et performants.

Ce n’est qu’un exemple parmi tant d’autres sur l’intérêt d’utiliser de tel langages. Bien sûr, si vous voulez coder un driver pour un noyau, un tel langage n’a aucun intérêt, ce n’est pas leur cœur de cible. Mais un scheduler qui a besoin d’être très modulaire l’est. Même un scheduler qui lance des sondes à tout bout de champ.

La solution à la stagnation de Nagios est de passer par un tel langage. Changer quelque chose avec une telle implémentation est faisable, voir même agréable (pas de compilation, langage qui ne pique pas les yeux…). C’est là qu’intervient Shinken. Il était un proof of concept, il devient une proposition pour une nouvelle implémentation. A titre d’exemple, rajouter un attribut a un objet (en gérant l’héritage, la valeur par défaut and co) revient à rajouter une ligne dans le code de Shinken, là où il en demande bien plus dans Nagios. Avoir une idée ne coûtera plus 2h de code, mais quelques secondes.

La proposition

J’ai proposé dans la mailing list devel de Nagios il y a une semaine que Shinken devienne la branche développement pour Nagios 4. Les réponses sont limitées pour l’instant. Ethan ne s’est même pas donné la peine de répondre (lit-il encore cette mailing list?), Andreas va tester un jour. Je vais relancer un peu le sujet, mais j’ai de moins en moins d’espoir d’atteindre mon objectif.

Un autre moyen sera de lancer un concurrent à Nagios, de mettre pas mal de coups de pieds au culs, puis de re-proposer l’inclusion. Mais combien de temps auront-nous perdu dans cette histoire?

Patch Nagios : SSL pour Ndo

Posted in Nagios by Nap on October 16, 2009 2 Comments

J’avais travaillé sur 3 patchs pour Nagios et je n’en ais évoqué ici que 2 pour la bonne raison que c’étaient les seuls à être intégrés. Et bien en fait c’est inexact : le troisième l’a été aussi :)

Ce patch permet d’établir une connexion chiffrée entre le module ndomod et ndo2db. En effet, avant tous les paquets étaient envoyés en clair sur le réseau. Ceci a beau être de la supervision, il y a tout de même le nom de toute nos machines, c’est assez embêtant. Avec le patch que j’ai proposé (commit sur http://nagios.git.sourceforge.net/git/gitweb.cgi?p=nagios/ndoutils;a=commitdiff;h=9d9dcccab9690c896a7f1c3d2015064430c5157a par Hendrik Baecker) il y a une option de plus sur ndomod.cfg et ndo2db.cfg : use_ssl.

Par défaut elle est à 0 pour un soucis de compatibilité. Une fois passée à 1, la communication sur socket (uniquement celle en réseau, pas cette sur le socket unix) est chiffrée.

Je n’ai pas réinventé la roue, j’ai emprunté le code à NRPE tout simplement. Je l’ai juste un peu adapté et mis au bon endroit.

Et voila, je suis dans le fichier THANKS de ndoutils maintenant :)

Shinken : Les grandes lignes

Posted in Nagios by Nap on October 6, 2009 2 Comments

Il y a quelques temps j’ai présenté dans les grandes lignes mon proof of concept Shinken, le Nagios en Python. Et bien il a plutôt bien avancé depuis. En voici un état des lieux et une idée de là où il va.

Architecture générale

Shinken est pensé pour les environnements distribués. Il est bien sûr possible de faire tourner tous ses composants sur une seule et même machines. Les composants justement, parlons en.

Architecture de Nagios

Nagios est (quasiment) monolithique. Il lit la conf, la traite, ordonnance les checks, les lance ainsi que les actions qui en résultent (les notifications et les event handlers). Il exporte également des informations vers un daemon externe pour mise en base de données.

Lorsque l’on a un petit environnement, tout marche bien, c’est pratique et presque rapide. Le problème se pose avec les grands environnements : Nagios est capable de gérer facilement jusqu’à 10000checks/5minutes sur un serveur moyen de gamme. Avec du tuning on peu arriver à 30000, mais gère plus, même en rajoutant pleins de CPU sur le serveur. La mise en place des environnements distribués n’est pas triviale (la preuve, elle demande un chapitre à part entière dans mon livre :) ). La tâche est encore plus hardue pour les environnements distribué ET hautement disponibles. Cette dernière exigence est très complexe à gérer si on ne veux pas perdre trop en performances, voir pas faisable du tout pour les très gros environnements sauf à mettre une armée de serveurs.

C’est là que vient Shinken : mettre en place un environnement distribué hautement disponible facilement. Le côté facile doit venir aussi de la gestion de conf. Nagios a une gestion de la configuration impressionnante, mais qui nécessite un gros travail manuel lorsqu’il est question d’environnements distribués.

De même pour donner des ordres à Nagios, il faut passer par le pipe nommé nagios.cmd situé sur le même serveur. Pour un serveur ça va, mais pour une dizaine, se souvenir sur quel serveur Nagios se trouve l’hôte que vous voulez rescheduler devient un peu plus complèxe…

Pour résumer la situation, l’architecture de Nagios est la suivante:

nagios-architecture

Architecture de Shinken

Shinken propose une solution à ces problèmes : le découplage des rôles de Nagios. Ces rôles sont éparpillés sur différents processus. Voici le schémas global, le rôle de chaque élément sera précisé plus bas:

shinken-architecture

  • Arbiter : lit la configuration, la découpe en N partie et l’envoi vers les autres processus. Il lit l’unique fichier nagios.cmd de l’architecture, et transmet les ordres à qui il faut. Il est également le garant de la haute disponibilité et la répartition de charge.
  • Schedulers (nom de processus Shinken) : il lit la conf que lui envoi Arbiter. Il peux y avoir N schedulers, chacun avec ses propres éléments (hôtes/services). Il est en charge d’ordonnancer les checks, de les proposer aux autres éléments, récupère le retour des checks, et propose des notifications/event handlers si besoin qui seront lancé par des éléments externes.
  • Pollers : Il peux y en avoir autant qu’on veut. Ils récupèrent les checks auprès des schedulers, les lance et renvoi le retour aux scheduler en question. Il n’y a pas intelligence ici. Ils récupèrent des checks, les lancent, renvoient le résultat. Point barre.
  • Actionner : De préférence il n’y en a qu’un (et un spare). Il est en charge de lancer les notifications et les event handlers. Il fonctionne de la même manière que les pollers, mais il est à part car on préfère en avoir un et un seul qui fait les notifications (pour les problèmes d’acès aux serveur SMTP ou les flux RSS par exemple).
  • Broker : Unique avec un spare, Les schedulers exportent des informations dans des ‘broks’, des morceaux d’informations. Ils sont récupérés par le Broker qui en fait ce qu’il veut après, suivant les plugins qu’il a. Chaque plugin traite l’information comme il le veut. Les plugins actuellement développés sont l’export du fichier service-perfdata et l’export dans la base merlin. La base ndo ne devrait pas tarder, mais ca sera plus long que pour celle de merlin, car elle est vraiment mal fichue!
  • Bah c’est tout. C’est déjà pas mal non? :)

Les éléments de charge sont éclatés d’où le load balancing. L’arbiter est le garant de la haute dispo, il réparti les conf aux vivants, et envoi les conf des éléments morts aux spare si un membre actif vient à mourrir (bah ca peut arriver hein, personne n’est parfait). L’administrateur n’a pas à se soucier de quel scheduler va gérer son élément (hôte), l’arbiter va découper la conf pour lui de manière automatique, et en faire des paquets les plus équilibrés possible en terme de charge. Shinken tiens son nom de là d’ailleurs :)

La configuration

Qui dit nouveaux éléments dit nouvelle configuration. L’arbiter mis à part, chaque élément a un élément de configuration qui lui est dédié. Elle est de la forme (par exemple ici pour les scheduler):

define scheduler{

name     scheduler-main

address      192.168.0.1

port      7768

spare        0

}

define poller{

name      poller-main

schedulers     scheduler-main, scheduler-spare

address      192.168.0.1

port      7771

}

Ceci doit être donné à l’arbiter dans le fichier nagios.cfg, comme n’importe quel autre configuration d’éléments dans Nagios. Ceci va permettre à l’Arbiter d’envoyer les configuration et de gérer les liens avec les schedulers, pollers and co. Je n’ai pas encore prévu de configuration locale au poller and co. Mais à part le port d’ouverture, il n’y aura pas gand chose à configurer.

Je prévois de faire en sorte de créer automatiquement un élément en local s’il n’est pas défini dans la configuration, genre dans le cas de l’import d’une configuration existante sans avoir à la modifier.

Les performances

J’en vois déja arriver avec leur grands sabots : “c’est en python donc c’est tellement lent qu’on ne va pas pouvoir tester sur de vrais environnements”. Ca aurait été sacrément inutile si c’était le cas. Je n’aime pas trop perdre mon temps. Allons directement à la mesure dans de vraies conditions : serveur Xeon bi-coeurs 3ghz. J’ai utilisé une configuration générée tout comme dans le chapitre 9 de mon livre (quoi,vous ne l’avez pas encore lu?). La latence nous permet de savoir si le programme a assez de ressources ou non.

  • Nagios dans sa configuration standard a stagnée a 9500 checks/5min, avec du tunning poussé, 25000. Je n’ai pas encore fait les tests avec export en base de données avec ndo2db;
  • Shinken arrive à 50000 avant que j’ai eu à faire du tunning de code…Et l’export en base de données fait en prime, le tout sur la même machine bien sûr.

Il n’y a pas de secret ici : La charge de Nagios vient du lancement de nouveaux process Nagios qui doivent lancer les plugins et le fait de “reaper” les résultats dans des fichiers plats. Shinken utilise un pool de process (les pollers ont un pool de workers) donc pas de surcharge ici, et les pollers envoient directement les résultats des checks en mémoire (technique d’objets distribués de type Corba, mais en autrement plus simple à utiliser). Pas de fichiers à parser, beaucoup moins de charge. “Et voila”.

Par contre ce n’est pas parfait : le lancement de l’Arbiter est légèrement plus lent que Nagios pour la lecture de la configuration, mais rien de rédhibitoire. Je vois revenir les gros sabots pour la consommation mémoire : Oui, ceci consomme plus de RAM que Nagios. Nagios est vraiment bien optimisé sur ce point, Shinken est “seulement” 3 fois plus consommateur, genre 250Mo pour les 50000 checks. C’est tout à fait acceptable à mon goût.

Bref, c’est testable même avec des grands environnements. Et ca veut dire que l’on peut encore améliorer Nagios. Bon reste à faire la partie Worker en C. Je l’aurais bien prise chez Apache, mais question de licence, ça le fait pas je pense. Puis le code est .. complexe pour juste une gestion de worker, mais bon c’est le C hein…

Ce qui est déjà fait

Les fonctionnalités principales de Nagios sont déjà dans Shinken:

  • ordonnancement de Nagios (HARD, SOFT, etc)
  • gestion des périodes de temps Nagios (sauf les exclusions)
  • checks passif
  • gestion des dépendances
  • macros
  • vérification de la fraicheur des états
  • export des données de performances
  • export des données dans une base MySQL de type Merlin
  • la gestion du flapping
  • le cache de checks pour les dépendances
  • services volatiles (pour les logs)
  • gestion du fichier de rétention

Pas si mal hein?

Ce qu’il reste à faire

Avant de le présenter “officiellement” aux auteurs de Nagios, je tiens à ce que la gestion des spares soient complète. De même que l’export vers la base ndo. Après je le présente, avec dans l’espoir de voir les bonnes idées s’il y en a (comme le pool de process) intégrée dans Nagios si c’est possible. (Bon tout est possible, mais en C ça devient beaucoup plus long à faire… beaucoup plus long à faire même…et pourtant j’aime le C, faut pas croire).

Ah oui, il faut que je fasse une VM de type VirtualBox avec Shiken et Ninja pour l’interface. En fait plusieurs VM seraient mieux pour l’aspect distribué.

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:

Next Page »