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

Related Posts:

Comments
  • Nap:

    Bon les caractères classiquement interdis sont `~!$%^&*|’”<>?,()=
    je vois bien la virgule moi :)
    Genre : srv-1,Cpu
    Ça rappelle un peu la manière d’écrire les services dans les servicegroups non?

    • lulesqueLUL:

      Dans mes plugins Nagios, je dois parfois traiter des arguments en nombre variable (ex : mono check de multi process): je les traite en chaine de caractère unique que le script splitte ensuite

      j’ai pris l’habitude sur cet argument unique, décomposé ensuite par le script, d’utiliser en séparateur la chaine “___”, n’ayant pas l’habitude de trouver cette chaine souvent par ailleurs:

      - passe partout
      - lisibilité améliorée de mon argument

      ca donnerait du srv-1___Cpu
      …. maintenant le séparateur est une chaine et non un caractère => impact fort sur le code ??

      cdlt

      • Nap:

        Merci pour la suggestion. Je pense que la virgule est plus naturelle et est déjà utilisée dans la définition des servicegroups par exemple. Il est plus simple de couper suivant un seul caractère qu’une chaîne en effet.

    • Nap:

      Bon c’est fait avec les , pour les services. Par contre couchdb a pour habitude de garder toutes les versions des documents. Ce qui fait que ça grossi grossi. Je vais voir comment limiter ce nombre de versions :)

      • Nap:

        Ah trouvé : supprimer l’ancienne révision ne fonctionne pas (enfin pas complètement), il faut aussi lancer un compactage sur la base. Super pratique ça…

  • lulesqueLUL:

    Bonjour,

    pour des checks avec un nb variable de paramètres , j’en utilise un seul que je découpe ensuite, avec la chaine “___” en séparateur : 3 carac au lieu d’un mais je ne suis plus embeté par des pb de caractères réservés et/ou speciaux.

    Ca donnerait Srv-1___Cpu

    cdlt

    eric

  • K:

    Hello,
    Quel est l’intérêt de l’utilisation de couchdb? Connais tu une interface qui sais lire ces données?