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 !

« Previous Page