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 : des modulateurs de résultats

Posted in Nagios by Nap on December 9, 2009

Je viens de rajouter dans Shinken deux options qui peuvent se révérer intéressantes : critical_is_warning et inverse_ok_critical. Les deux options sont utiles pour remplacer des sur-chouches de checks comme negate ou nocritical.sh.

Le cas des serveurs de Qualifications

L’option critical_is_warning est utile pour les serveurs de Qualification. Il est en effet coutume d’avoir du rouge dans l’interface de supervision (et donc CRITICAL) si et seulement si c’est important et que cela demande une intervention immédiate. Mais que faire si le service remonte un état CRITICAL sur une machine de Qualification? Si deux erreurs arrivent sur l’interface, une sur un serveur de PROD, l’autre sur un serveur de Qualif, il va falloir regarder qui traiter en premier, et surtout connaître si les serveurs sont en Prod ou non. Pour les petits environnements point de problème, pour les plus gros, c’est plus difficile…

C’est pour cette raison qu’il peut être pratique de “déclasser” les résultats d’un service sur un serveur de Qualification de Critical en Warning. Un script comme nocritical.sh (si exit_code==2 ->exit_code=1) peut être utile. Le problème est que l’on devait avoir des check_command dédiées pour cela. La moindre modification était double (version avec et sans nocritical.sh).

Avec critical_is_warning, l’administrateur va pouvoir tagguer une machine comme étant non critique. Ce paramètre sera hérité par les services (héritage implicite) si le service ne le défini pas déjà. Ainsi, il est possible d’avoir pour la plupart des services ce paramètre d’absent (et donc hérité de l’hôte, 0 par défaut) et certains services critiques partout (comme ceux concernant la sécurité) avec critical_is_warning à 0. Les hôte taggué critical_is_warning à 1 seront automatiquement, et avec les même services que les autres, limités au niveau Warning. sur une configuration comme la mienne, ceci divise tout simplement le nombre de service par deux, ce qui n’est pas négligeable :)

Les services clusters passifs

Une autre problématique classique concerne les service sur les services passifs de cluster. Ils ont besoin d’être l’inverse de l’actif. Ici il n’est pas possible d’imaginer un attribut sur l’hôte, car il est cluster pour un service, mais pas pour tous les autres de l’hôte (comme le CPU par exemple). Le paramètre inverse_ok_critical fait donc le même rôle que la célèbre sonde negate (code retours : 0->2, 2->0). Il s’applique sur un service. Il va permettre de ne plus avoir de duplication des check_command, mais ne règle pas le besoin de définition d’un nouveau service. Il n’est pas dit que ce paramètre soit la solution ultime à ce problème des clusters, mais c’est une première réponse à cette problématique.

Byebye negate, tu nous auras bien aidé.

Ordre d’application

Il peut y avoir un service taggué avec ces deux paramètres. Quid alors d’un résultat CRITICAL? Et bien c’est le critical_is_warning qui l’emporte. Mais il faut être un peu tordu pour mettre les deux à vrai dire…

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?

Shinken : gestion des noms en UTF8

Posted in Nagios by Nap on December 1, 2009

J’ai voulu m’amuser et mettre des noms en UTF8 pour les hôtes et services. Une fois modifié le character_set des bases merlin et ndo (de base en latin1…) ça a roulé sans problèmes, export en base compris. Merci Python :mrgreen:

Shinken : Quoi de neuf docteur?

Posted in Nagios by Nap on December 1, 2009 4 Comments

Shinken a bien avancé ces derniers temps. Dans le désordre :

  • Support de l’export en base NDO pour MySQL et Oracle (merci à Icinga pour leur fichier Oracle.sql d’ailleurs)
  • Les daemons sont maintenant réellement des daemons (option -d et ils ont leur propre fichier de conf pour choisir par exemple le port et l’interface d’écoute à utiliser)
  • Vérifications des checks orphelins (en gros dans un poller depuis bien trop longtemps)
  • Support du fichier ressource pour les macros $USERN$
  • Tunning mémoire pour les hôtes (utilisation des slots python comme pour les services)
  • Les plugins des brokers ont pris du galon : désormais ils sont configurable dans le fichier de conf principal avec un define plugin. Ils sont après rattachés à un satellite (pour l’instant seul les brokers peuvent les utiliser). De cette manière, il est possible d’instancier un même type de plugin plusieurs fois pour un même daemon. L’exemple le plus explicite de cela concerne la création de deux fichier service-perfdata ou bien l’export dans deux bases ndo.
  • Les plugins des brokers ne peuvent plus faire planter le broker. S’il y a une exception non catchée par eux, le module est désactivé.

La partie NDO n’est pas encore complète, mais le principal est là. Reste à l’optimiser, car pour l’instant la base morfle bien lorsque l’on créé beaucoup de services. La base Merlin est bien plus performante, mais bon, une fois mes cours de SGBD relus, peut être que mes requêtes NDO seront un peu plus efficaces aussi :mrgreen:

Shinken : l’art de l’inspiration

Posted in Nagios by Nap on November 14, 2009

Le partage des idées

Dans tout ce qui est libre on partage le code bien sûr, mais encore plus important on partage les idées. Deux modifications que j’ai apportées ces derniers temps aux Workers (utilisés par les pollers/reactionners) reflètent cela.

Le problème des workers est double : avoir LE bon nombre de Worker et que chaque worker soit le plus efficace possible. Le tout bien sûr pour réduire leur charge au maximum.

Avoir le bon nombre

Le nombre de Worker n’est pas si simple à déterminer. On peut placer un nombre arbitraire (10, 30, 100 ou même 250) mais il ne sera jamais optimal, sauf à faire de nombreuses tentatives. De plus, mesurer leur utilisation n’est pas chose aisée.

Sur un petit environnement, avoir 4 workers sera plus que suffisant. Sur les très gros, 30 n’est pas du luxe. En effet, si on prends un check simple qui fait toujours la même chose, il est relativement simple de savoir combien il en faut. Mais avec des checks qui mettent un temps aléatoire pour s’éxécuter, ça devient tout de suite plus dur.

Après une petite réflexion, leur nombre optimal est venu:

temps_moyen_checks*checks à traiter

Bon le nombres de checks à traiter est plus que facile à obtenir. Le temps moyen des checks un petit peu moins. Je suis parti d’un temps moyen depuis le lancement du daemon mais le problème est que le nombre de checks à la seconde n’est pas tout le temps le même, la nuit ça peut être plus calme par exemple. J’ai utilisé un calculun calcul similaire au load average Unix (une moyenne mobile exponentielle). Ceci permet de ne pas avoir de lisser un peu le nombres de workers demandés le tout en ayant une réactivité intéressante car j’ai pris un load à une minute.

Ceci n’aurait pas été possible si les auteurs d’Unix d’auraient pas utilisés ce type de moyenne et que Linux m’ait montré le code (tout simple en plus..). Au passage j’ai cré une Class spéciale pour ce type de calcul afin de pouvoir le réutiliser dans d’autres parties du code.

Pour l’instant c’est la partie montante du nombre de worker qui est utilisé. Il faut que je m’occupe de la partie descendante (où comment flinguer intelligemment les workers).

Attendre le temps qu’il faut

Revenons un peu sur les temps des checks. Ils sont aléatoires. Souvenez vous : j’ai changé le code du lancement des checks sous Unix par la variante Windows (avec un joli gain de perfs à la clé et une dépendance de moins). MAIS cette technique repose sur une boucle sur poll (pas de select malheureusement :( ) avec un sleep au milieu. OK, il suffit d’attendre le temps du checks… Ah flûte, on ne sait pas a priori combien de temps il va attendre. Attendre trop et c’est de la latence et un worker qui ne fai rien (donc plus de workers nécessaires). Attendre trop pu, c’est une latence minimale, mais un poll lancé trop souvent et donc de la charge inutile…

Bref, il faut attendre le BON temps, ou a défaut le bon ordre de grandeur. Là on peut s’inspirer du TCP.

Oulala, quel est le rapport entre le TCP et une boucle sur le poll? Et bien le slow start de TCP bien sûr! TCP est fait pour tout type de connexions, rapides, lentes, moyennes. Il doit optimiser le débit. Pour cela il augmente dès le début de la connexion le débit envoyé à chaque envoi. Fois 2 à chaque envois. Dès que ça ne passe plus, il a trouvé l’ordre de grandeur, et passe par une augmentation linéaire.

On va utiliser un système similaire. Nous voulons l’ordre de grandeur (une fois qu’on a trouvé, c’est fini). On va donc partir d’une boucle toute simple :

wait_time = 0.0001
while process.poll() is None:
time.sleep(wait_time)

Et la changer en :

wait_time = 0.0001
while process.poll() is None:
wait_time = min(wait_time*2, 0.1)
time.sleep(wait_time)

En une ligne on a une recherche de l’ordre de grandeur. Simple non? Ici j’ai borné à 0.1s. 10 appels systèmes par secondes sont tout à fait acceptable, 10000 beaucoup moins. On change donc un nombre d’appel en O(n) en O(log2(n)).

Il est marrant de voir à quel point les algo les plus remarquables sont toujours d’une simplicité étonnante…

Moyenne mobile exponentielle

Next Page »