Couchdb dans Shinken

Posted in Shinken by Nap on December 17, 2009 8 Comments

J’ai lu il n’y a pas longtemps des articles sur Couchdb (http://couchdb.apache.org). J’ai voulu voir un peu ce que ça donne en vrai. L’intérêt de ce type de base est de na pas avoir de table, mais une liste de documents. J’ai donc essayé de faire un plugin Broker pour avoir un export en Couchdb des services (faut bien commencer par quelque chose).

Ca tombe bien, il y a un module python-couchdb (http://code.google.com/p/couchdb-python/) ultra simple à utiliser (bah c’est du Python hein). Après une belle frayeur sur les perfs (40ms par entrée, ça commence à faire beaucoup à mon goût) dû au protocole Nagle de TCP (pour beaucoup d’envois de faible taille, il faut mettre la socket en NO_DELAY), j’ai été un peu plus rassuré : 1000 entrées insérées en 2secondes. Ce n’est pas ultra rapide, mais ce n’est pas ultra lent non plus. Ce que ça donne?

Ca :

shinken-couchdbPour l’instant seul la création des documents est faite, et ce uniquement pour les services (mais le reste est rapide). Pour la mise à jour (genre après un check :) ) il va falloir que je me penche sur les ‘views’ car il va falloir que je retrouve le service avant de le mettre à jour. En effet, pour l’instant l’id du document est son id (unique pour chaque service lors de la lecture de la conf). Je mettrais bien un truc du genre “srv-1/Cpu” comme id, un truc simple. Mais je ne me rappelle plus si dans Nagios les / sont autorisés dans les noms d’éléments (sinon comment savoir quel est la partie host de “srv-1/CPU/1″ pour le service CPU/1 de srv-1).

Quelqu’un a une proposition pour l’id des services? Si on arrive à trouver un mix du nom d’hôte/nom de service, on n’a pas besoin de faire de views pour retrouver l’id dans co, ça sera autrement plus efficace :)

PS: pour preuve que python-couchdb est ultra simple à utiliser : le broker reçoit les données dans un dictionnaire python (dict). Et bien pour créer le “document” en base, même pas besoin de créer un INSERT, VALUES and co, juste : db.create(dict) :mrgreen:

Oui le Python, c’est vraiment pour les feignasses 8-)

Shinken sur ZDNet!

Posted in Shinken by Nap on December 16, 2009 3 Comments

http://www.zdnet.de/it_business_technik_nagios_alte_probleme_und_neue_perspektiven_story-11000009-41524548-1.htm

C’est Gerhard Laußer qui est interviewé.  C’est un expert Nagios de la société ConSol (www.consol.de) et qui m’a déjà fournis de nombreux patchs pour Shinken. Dans l’article et l’interview, Garhard parle de Nagios et de son activité récente. Vu que je ne parle pas un traitre mot d’allemand, je n’ai pu lire que la traduction google de l’article (http://translate.google.fr/translate?js=y&prev=_t&hl=fr&ie=UTF-8&layout=1&eotf=1&u=http%3A%2F%2Fwww.zdnet.de%2Fit_business_technik_nagios_alte_probleme_und_neue_perspektiven_story-11000009-41524548-1.htm&sl=auto&tl=fr) mais Gerhard m’a dit avoir été sympa avec Shinken dans l’interview :)

Merci à lui.

Python et le Data-Driven programming

Posted in Shinken by Nap on December 16, 2009 4 Comments

Suite au post d’un journal sur linux-fr concernant Shinken et l’avenir de Nagios (http://linuxfr.org/~naparuba/29141.html) certains m’ont demandé pourquoi j’ai choisi le Python (www.python.org) pour Shinken. J’ai répondu que 80% du choix était dû à mon goût perso, 20% pour les qualités du langages sur la résolution du problème. Les 20% sont en fait le module Pyro (http://pyro.sourceforge.net/)pour les objets distants (un peu comme Corba, mais autrement plus simple à utiliser et plus dynamique (pas de déclaration de squelette)).

Et les 80% restant?

On peu un peu se demander ce qu’il y a dans les 80% restant. Outre le fait que le langage ne pique pas les yeux (et évite les nœuds … au cerveau), et qu’il a d’intégré un module pour la gestion des pools de process (lancement des checks en parallèle),  il a de réelles qualités sur son dynamisme qui permettent d’utiliser une vaste panoplie de paradigme de programmation. Il ne les fait pas tous bien entendu (genre la programmation logique (et le prolog)), mais il permets déjà d’utiliser les principaux:

  • programmation itérative et récursive
  • programmation orientée objet
  • programmation orientée aspect (decorator)

Bon c’est bien, mais le rapport avec la choucroute il et où? Et bien suivant la situation, avec Python on peut choisir, c’est plutôt sympa. Lorsque vous gérez des graphes, le récursif s’impose de lui même (ou alors vous être vraiment tordu…), en règle général c’est de l’objet, et dans quelques cas particuliers l’aspect.

Une matrice de création nommée ADN

Concernant l’objet, la création des objets n’est pas classique pour la plupart des types dans Shinken. Nagios utilise des techniques d’héritages sur des objets (hosts/services) qui ont de multiples propriétés (et c’est rien de le dire). Alors m’amuser à faire des constructeurs de 5 lignes non extensibles facilement, non merci. Si c’est pour faire ça, autant rester à faire du C.

C’est là que vient le data-driven (enfin je crois que c’est comme ça que ca s’appelle) : vous décrivez votre objet dans un tableau quelconque, et au lieu de coder ce que vous devez faire pour chaque propriétés, vous faire une boucle sur votre tableau de description pour faire l’action, avec outre le nom de la propriété, les informations dans ce tableau sur quoi faire pour telle propriété. C’est tout (bah oui, c’est tout con, d’ailleurs je l’ai fait avant de savoir comment ça s’appelait…). L’intérêt? Aucun si vote objet a trois pauvres propriétés, mais énorme si elles commencent à devenir nombreuses (genre une bonne vingtaine).

Comme pour la plupart des techniques de programmations, l’intérêt est d’avoir une factorisation des informations. Ici vos propriétés (et les propriétés de ces propriétés…) sont définies dans un seul endroit. Si vous voulez changer, rajouter, supprimer quelque chose, pas besoin d’aller parcourir l’ensemble du code. Celui-ci ne connait pas ce que vous avez mis comme données dans vos tableaux. Il sait les traiter, mais ne connait pas à l’avance ce qu’il y a dedans. Le tableau est une sorte d’ADN de l’objet : c’est sa matrice de fabrication.

Où qu’on le met cet ADN?

Ce qui est embêtant est d’accéder à ce tableau lors de vos traitement. Bien sûr il y a la méthode consistant à le mettre en variable global, mais les variables globales c’est un peu comme le goto : le mal absolu. Mettre le tableau dans chaque objet? Bof, c’est crade, un objet n’a pas besoin d’avoir son ADN d’accroché pour vivre une fois crée (vous utilisez votre ADN vous? Non, vous utilisez les protéines qu’il a permis de fabriquer). Python nous aide ici. Si vous faite objet.__class__ vous obtenez la classe de l’objet. Et oui, une classe est un objet. Et un objet en python peut se voir accrocher des propriétés… genre notre tableau.

Si on rajoute ceci à un héritage de nos objets à une classe “Item” qui va faire le travail de construction, on obtient une fabrique de n’importe quel objet le temps que l’on définisse son ADN dans la classe de l’objet. Pratique non? C’est diablement efficace pour factoriser le code à sa plus simple expression.

Et au final on y gagne beaucoup?

Vous voulez un exemple? Le code de Nagios pour juste la fabrication des objets avec les techniques d’héritages and co prends à lui seul plus de 11K lignes. Shinken dans son entier (architecture distribuée, configuration, envoi dans les bases de données, ordonnancement, etc) en prends un peu plus de 8K. Owned comme dirait l’autre.

Il fait chaud chaud cet hiver

Posted in Shinken by Nap on December 15, 2009 2 Comments

Ca y est, les hot_period sont implémentées (cf http://www.gabes.fr/jean/2009/12/14/hot-periods). Au passage j’ai viré la dépendance à python-graph-core, plus d’erreurs avec digraph suivant la version de python-graph que vous utilisez. En plus les histoire de graph c’est toujours marrant…

Hot periods

Posted in Shinken by Nap on December 14, 2009

Ce post fait suite à celui des modulateurs de code retour. Pour rappel, ils permettent pour des services de modifier les codes retours suivants ce que l’on veut. Les deux proposés sont:

  • inverse_ok_critical : pour les services actifs/passifs
  • critical_is_warning : pour les services sur des machines de priorités plus faibles comme celles de QUALIFICATION.

Pour les machines de Qualif, nous avons aussi le cas de machines de production faible : ce n’est pas de la production 70% du temps, mais critique les 30% restant. On peut mettre un critical_is_warning pour ne pas être pollué visuellement en rouge pendant une période de faible activité, mais on perd l’avantage de la visibilité en période chaude.

Personne ne voit où je veux en venir? Et bien oui, ces périodes chaudes justement :)

Déjà tout comme critical_is_warning est settable sur un host et héritable implicitement sur les services, cette période chaude est portée par l’hôte, et si l’administrateur le veut, est settable sur le service tout de même. Cette période chaude dé-inhibe le critical_is_warning : pendant la période chaude, on repasse sur un comportement normal, avec “critical is critical”.

Un exemple? Et bien imaginez une application de paye, c’est critique 1semaine par mois (mais alors HAUTEMENT critique hein), le reste ça mérite un warning (sauf sécurité, mais là on ne met pas critical_is_warning…). Et hop, encore du rouge qui disparait sur l’interface :mrgreen:

La propriété utilisée? hot_period (sur host et/ou service si vous avez bien suivi).

Bon reste à coder cela, mais ça ne va pas être très long, mais déjà je vire la dépendance à python-graph-core… (et hop, retour dans le monde merveilleux des graphs orienté et des parcours en profondeur).

Mes premiers patchs !

Posted in Shinken by Nap on December 10, 2009

Je viens de recevoir mes premiers patchs pour Shinken. Ca fait quelque chose :oops:

C’est Gerhard Lausser qui me les a proposés. Patchs très bien écrit et permettant d’implémenter la directive cfg_dir ainsi que les trailing \ (permet d’avoir une ligne de conf sur plusieurs lignes) dans les fichiers de conf. Merci beaucoup à lui !

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:

« Previous PageNext Page »