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

Shinken : la 0.1 est arrivée!

Posted in Shinken by Nap on May 31, 2010 3 Comments

Elle est enfin là, et elle envoie déjà du gros

Bonjour,

La version 0.1 de Shinken est enfin arrivée :mrgreen:

On va dire que c’est une bonne grosse 0.1 car mine de rien elle possède pas mal de fonctionnalités :

  • prise en compte de la configuration de Nagios quasi complète
  • reprise des sondes de supervisions et de notifications
  • multiplateforme (testé sur GNU/Linux et Windows, mais doit fonctionner sans soucis partout où roule Python)
  • hautement performant : j’en ai déjà parlé dans ces colonnes, enlever les erreurs de conception de Nagios, ça aide…
  • architecture distribuée et hautement disponibles (bah oui, c’est un peu le but de l’outil hein…)
  • modification à la volée des résultats en fonction de timeperiods
  • configuration des escalades de notifications bien plus simple qu’avec Nagios
  • UTF8 est géré (bah c’est du Python, je ne me suis pas foulé pour l’avoir hein…)
  • un super logo (quoi? c’est une super fonctionnalité nan?)
  • support des exports classiques (Mysql avec NDO et Merlin, Oracle avec NDO, Livestatus et même Couchdb 8-) )
  • plein d’autres trucs qui vont me revenir une fois que j’airai publié ce post….

Les manques par rapport à Nagios existent, mais ne sont pas loquant pour la quasi totalité des utilisateurs :

  • manque les / N de saut de jours pour les timeperiods (mais bon, Shinken a les exclusions de timeriods LUI, même si je comprends pourquoi ce n’est toujours pas OK dans Nagios..)
  • pas de variables d’environnements _NAGIOS* lors du lancement des sondes (c’est un oubli tout simplement car je n’utilise pas cette fonctionnalité chez moi), mais peu de sondes l’utilisent de toute manière
  • pas de commandes de types OCSP : dans Nagios elles ne servent qu’à la partie distribuée, donc bon…
  • 10 ans de tests de l’application derrière elle… bon ça je ne vais pas le régler du jour au lendemain je crois… :lol:

Mais comment on la teste?

Le code est dispo sur le site officiel du projet : http://www.shinken-monitoring.org. Outre le classique tarball installable très facilement (Python + Pyro en apt-get et hop, c’est parti :) ), j’ai tout prévu pour les feignants (qui à dit “administrateurs efficaces”?) : une VM toute prête à être lancée est disponbile sur le site. Elle est importable sous VirtualBox et VMWare.

Mais comment on peut tester facilement un service daemon? Bah avec les interfaces wbe préinstallé pardi ;-)

Elles sont au nombre de deux : Ninja et Thruk. Elle s’accèdent facilement avec un http://IPDELAVM/ (connectez vous avec le compte shinken/shinken, puis faites ifconfig pour voir votre IP, et enfin lancez ./launch_all.sh pour lancer Shinken et Thruk).

Bref, aucune excuse pour ne pas tester. La configuration en place est un exemple de distribuée et hautement disponible : deux ordonnanceurs actifs et un en spare. De quoi killer du process sans peur :)

Le fichier README_FIRST.txt vous aidera d’ailleurs lors de ces tests en proposant des kill et moyens de vérifier que ça tourne toujours.

Et ensuite? Seedcamp!

Ok, la 0.1 est sortie, elle est chaude, possède sûrement un ou deux bugs, mais après, il se passe quoi? Et bien vous serez ravi d’aprendre que Nagios lance seedcamp, un concours pour des propositions d’amélirations de Nagios ou d’addons. La description complète est dispo sur le site de Nagios. Et bien vous avez devinez, Shinken va participer! Il est lancé demain 1er juin. Shinken compte bien être le premier projet proposé :mrgreen:

Outre le fait que ça me fait bien marrer de participer (en plus si je gagne, ça me financera assez pour aller présenter Shinken un peu partout), c’est l’occasion rêvée de voir un peu comment est vu Shinken par rapport au Nagios Corporate : les participants sont évalués par la communauté. Bien entendu, si vous liez en bas le réglement de seedcamp, il y a des possibilité d’exclusions pour les projets farfelus. Je pense (espère) que Shinken ne rentre pas là dedans. Je pense donc que Shinken sera évalué de manière pertinente par celle à qui il est destiné : la communauté Nagios.

Si exclu?

Et s’il est exclu? Bah là le message sera clair : les possibilités d’inclusions dans le projet officiel Nagios sont morts. Shinken sera dès à présents libres (enfin encore plus que maintenant) par rapport au projet Nagios. La compatibilité des interfaces, sondes et configurations seront conservées, mais il n’y aura plus aucune retenue quand à rajouter des modules qui sont trop inovants par rapport à Nagios (comme un module de configuration en base par exemple).

Si écrasé?

S’il ne gagne pas et fait un score minable? Bah je me retire au tîbet… nan je blague, fait trop froid pour moi là bas. Mais je continuerai à l’améliorer jusqu’à ce qu’il remporte les suffrages de la communauté Nagios je pense.

Et si c’est le champion?

S’il gagne haut la main? Là, ça va être drôle. Le fait de revenir sur le choix du Python sera un niet ferme s’il n’est pas motivé techniquement, et puis bon le C c’est bien dans un noyau, mais en dehors faut vraiment en avoir besoin hein… Ceci dépendra des conditions d’inclusion de Shinken dans Nagios en fait.

Les vraies chances de réussites

En fait au vu de l’histoire récente, je serai le premier étonné de la victoire de Shinken. Pas pour ses qualités techniques ou ses nouvelles possibiltiés d’architecture. En elles j’ai toute confiance. Non, c’est sur le plan humain que je pense que c’est difficile : Ethan n’a jamais pris officiellement position sur Shinken, même en privé. Une exclusion de seedcamp m’effrai un peu, mais au moins on y verra plus clair.

Mais qui sait, la réunification tant attendue est peu être au bout du chemin, en tout cas, le proposition va être faite, on sera vite fixé.

Et ensuite seedcamp?

Peu importe seedcamp et ses résultats, de nombreuses choses sont encore en cours pour Shinken. Si d’ailleurs vous souhaitez filez un coup de main, c’est sans aucun problème :mrgreen:

La roadmap/ticket tracking est là pour ça sur source forge.

Bon test de cette première version. dites moi un peu ce que vous en pensez, ainsi que du tout nouveau site de Shinken d’ailleurs :-)

Shinken : example de Hack rapide du code

Posted in Programmation, Shinken by Nap on May 5, 2010

Un exemple de hack rapide

Dans un précédent post, j’ai déjà parlé des méthodes de développement que j’ai utilisé dans Shinken. Tout ceci a pour but de faciliter le développement par la suite, comme le rajout facile d’une propriété sans avoir à se soucier des héritages, distributions sur les différents éléments de l’architecture, etc etc.

Nous allons en voir un exemple avec un cas simple : le rajout d’un paramètre pour l’historique du flapping dans Shinken. En effet, Nagios et Shinken sont capables de détecter un élément qui fait le “yoyo” entre deux états. Plutôt que de spammer les users avec des notifications UP/DOWN/UP/DOWN, les schedulers sont assez malin (entendez utilisent un bête algorithme) pour s’apercevoir que l’état à changé X% de fois au cours des N derniers tests. La valeur X était déjà paramétrable pour les hôtes et les services, mais celle de N était hardcodée à 20 états.

Le problème c’est que 20 états ce n’est pas assez pour détecter un yoyo sur toute la nuit. Il arrive donc souvent des cas où l’on est averti pour rien, juste car on ne peux pas augmenter cette valeur. C’est dommage :cry:

Et bien plus maintenant :mrgreen: !

Je l’ai rajouté dans Shinken en quelques lignes qui vont vous monter à quel point c’est simple d’aller hacker dans ce code, 5 lignes seulement dans notre cas :-D

La modification

Tout se joue dans deux fichiers sources :

  • config.py : qui gère les paramètres de configurations globaux
  • schedulingitem.py : qui gère les algorithmes d’ordonnancement, des demandes de checks et autres.

Dans le premier (config.py) on remarque un tableau nommé properties vers le début du fichier avec toutes les propriétés possibles pour le fichier principal (nagios.cfg). Qu’à cela ne tienne, on va rajouter notre nouvelle propriété :

‘flap_history’ : {’required’:False, ‘default’:'20′, ‘pythonize’: to_int, ‘class_inherit’ : [(Host, None), (Service, None)]},

On rajoute donc le paramètre flap_history, qui n’est pas obligatoire (required=False), vaut par défaut 20, se transforme en objet int depuis la lecture de la chaîne de caractère dans le fichier, et va être présentée aux classes Host et Service avec ce même nom de flap_history (rôle de None, expliqué un peu plus haut dans le code, si vous mettez un nouveau nom, c’est lui qui sera utilisé pour cette classe).

Et voila, c’est tout pour la configuration ! Et oui, rien de plus. L’Arbiter va lire la configuration, transformer en entier la valeur, mettre 20 si elle est absente et va la fournir aux configurations envoyées aux schedulers automatiquement ! Là, ne pas hacker un tel code, c’est plus que de la fainéantise :lol:

On a réglé le problème de la configuration, maintenant on va utiliser notre nouvelle propriété. Ceci se passe dans deux fonctions du fichier schedulingitem.py : add_flapping_change et update_flapping. La première rajoute le changement d’état sur la pile de 20 éléments et s’assure que la pile fait toujours au plus 20 éléments. La seconde fait le calcul de pourcentage de changement à proprement parlé.

Les schedulingitems sont les hosts/services (une classe commune pour factoriser le code), et l’objet est nommé self en Python. On a dit que la propriété a été envoyée sur les classes Host et Service car c’est un paramètre global à tous les hôtes et services, pas la peine de le multiplier par le nombre d’hôtes et services. En Python, pour accéder à sa classe (qui est un objet comme un autre), il suffit de faire :

self.__class__

Donc là pour obtenir notre valeur, il suffit de faire :

flap_history = self.__class__.flap_history

On remplace les trois occurrences de 20 qui trainent dans le code par flap_history et c’est réglé, on peut tester/commiter 8-) :

if len(self.flapping_changes) > flap_history:

r += i*(1.2-0.8)/flap_history + 0.8

r = r / flap_history

Au final

Nous avons vu la définition et l’utilisation d’un paramètre global dans Shinken. C’est très simple, et il ne faut pas se priver :-) Nous verrons une autre fois le rajout d’un paramétrage dans un service ou un hôte, c’est encore plus simple qu’ici car il n’y a pas besoin de passer par l’accrochage dans les classes Host et Service. Mais ce sera pour une prochaine fois, j’ai un git push à faire.

Si vous souhaitez hacker vous aussi, n’hésitez pas :

git clone git://shinken.git.sourceforge.net/gitroot/shinken/shinken

J’accepte volontiers les patchs :)

Juste pour info, dans le code de Nagios, si on voulait faire la même chose, il faudrait changer la macro MAX_STATE_HISTORY_ENTRIES en simple variable :

grep -r MAX_STATE_HISTORY_ENTRIES * | wc -l
30

30 lignes au minimum juste pour la partie traitement! Je n’ose même pas regarder combien de lignes ceci va coûter pour la configuration, mais bien plus d’une, ça c’est sûr… :-?

Notez bien que je ne dis pas ça pour me moquer des développeurs de Nagios, comme quoi le code est imbitable non, car je n’aurais sûrement pas fait mieux en C.  C’est juste pour illustrer que parfois, utiliser des techniques de développements avancées (le développement dynamique qui a un peu irrité lors de l’annonce de Shinken sur la mailing list), ça ne fait pas de mal à l’efficacité…

Shinken : tagguez vos pollers

Posted in Shinken by Nap on May 5, 2010

Découpage organisationnel/technique

Dans l’Architecture de Shinken, un point important concerne les Realms (royaumes) qui servent à découper dans pans entiers d’infrastructure, comme un site distant par exemple, ou bien un client pour une entreprise qui propose une prestation de supervision.

Ce découpage est donc soit organisationnel, soit technique. Mais pour ce dernier, le choix du découpage se fait sur des critères géographiques, en terme de réseau principalement (pour ne pas avoir de fréquentes communications inter-continents par exemple).

Shinken fonctionne sur Windows (avec des services et tout et tout), et il est donc tentant de placer un poller sur un tel OS afin de lancer directement ses checks depuis une machine (et un compte de domaine) qui a les droits sur les autres machines, pour faire du WMI par exemple.

Mais comment faire en sorte que les commandes pour Windows partent sur ces pollers “Windows” et pas les classiques pollers “Linux”? On peut se dire que l’on utilise les realms, mais ce n’est pas une bonne idée en fait. Les realms sont des cloisonnements, il n’y a pas d’échange entre les schedulers (même au sein d’un realm d’ailleurs). Donc si un administrateur défini un Realm Linux et un Realm Windows, il va pouvoir obtenir l’effet souhaité (des commandes qui vont sur les bons pollers), mais à un prix énorme : plus de liens (dépendances) entre les hôtes Linux et Windows…

Cloisonnement technique

C’est pour cela que dans un même realm, il doit être possible de cloisonner “techniquement” les commandes sur des pollers. Ce cloisonnement, qui va être optionnel bien sûr, se fera dans la configuration avec une nouvelle option : poller_tag. Comme son nom l’indique, un poller va avoir un ou plusieurs tags, et les checks vont pouvoir également être taggués.

Si le tag au niveau des pollers est simple, se pose la question du tag des commandes : à quel niveau doit-on tagguer? commands, services, hosts? Et pourquoi pas les 3 finalement? L’héritage serait host->service->commands.

Le tag des commands est simple : une commande définie comme un exe au sens windows (PE et non pas ELF) sera naturellement tagguée “windows-poller”. Les tags au niveau service/hosts seraient un peu comme un “mini-realm” : au lieu de définir un realm complet (avec un couple scheduler/poller) pour une DMZ par exemple, il peut être pratique de juste dédier un poller (ou deux) dans cet environnement, et de tagguer les hôtes/services.

Un mini-realm?

Ceci n’est pas complètement orthogonal aux realms je l’admets, mais c’est plus une réponse aux “proxy nrpe windows” qu’à un réel besoin organisationnel que proposent les Realms.

Au passage, cette implémentation va être un bon exemple de “Hack” possible de Shinken. Je vais essayer de noter/expliquer l’implémentation dans un document afin de montrer que développer pour Shinken n’est pas complexe, loin de là :)

Shinken : quelques news sur la prochaine 0.1

Posted in Shinken by Nap on April 26, 2010 2 Comments

Bonjour,

Ça fait quelques temps que je n’ai pas parlé de Shinken. Outre le fait que j’avais des articles à finir pour LinuxMag et autres (comme celui sur l’art de la guerre appliqué au logiciel libre), les points traités ces temps-ci sur le projet ne sont pas spectaculaires, mais pourtant importants.

Tout d’abord le projet a une véritable documentation. Celle-ci est basée sur le formidable travail de l’équipe monitoring-fr qui a transformé la documentation HTML de Nagios en DocBook. Ce format est en XML, mais il n’est pas si mal que ça. Il me rappelle un peu le LaTeX en fait. Un grand merci à l’équipe monitoring-fr pour ce travail titanesque. Celui-ci permet en effet d’automatiser des exports de la configurations dans différents formats. Les deux utilisés pour l’instant sont le PDF et le XHTML. Ce dernier est justement à jour sur le site du projet. Là encore, le style CSS utilisé est un mix entre le style utilisé par l’équipe monitoring-fr et celui du site de Shinken :mrgreen:

Dans la configuration sont présentes les informations pour configurer les satellites afin de monter une architecture distribuée hautement disponible. Une page a été rajoutée également par rapport à la documentation Nagios classique : une mise en place sur Windows ! Sur ce système, il est en effet possible (et même très simplement) de mettre en place Shinken en tant que Service Windows. Un cas particulier peu intéresser du monde : imaginez un daemon poller qui tourne avec un compte de domaine qui a le droit de faire des requêtes WMI sur les autres Windows du domaine? Plus besoin de monter une application pour faire un relai WMI, c’est natif avec Shinken 8-)

Je n’ai pas encore fait de tests de performances sur cet environnement, mais je ne m’attends pas à avoir 150000checks/5min comme sur un Linux car Windows est bien moins à l’aise lorsqu’il s’agit de lancer des processus. D’après ce que j’ai commencé à voir, un serveur devrait être largement suffisant pour une moyenne entreprise.

Pour la version 0.1, il ne reste plus grand chose en attende en fait. La documentation est perfectible, mais acceptable. Il y a encore un petit bug avec la gestion des Downtimes sur la partie Notifications, mais Gerhard est en train de l’éradiquer, encore merci à lui ;-)

Le site devrait bientôt avoir une petite animation sur le fonctionnement de Shinken par rapport à son architecture, mais je n’en dit pas plus, ceci sera une petite surprise pour la 0.1

Les escalades de notifications enfin simples à mettre en place

Posted in Shinken by Nap on January 25, 2010

J’ai rajouté dernièrement le support des escalades de notifications. Pour rappel, elles permettent d’envoyer à d’autres contacts les notifications lorsqu’un problème persiste. Par exemple, vous pouvez définir pour le service CPU sur main-server un escalade qui va prévenir les chefs si au bout de 3 notifications le problème n’est pas résolu :

define serviceescalation{
host_name       main-server
service_description      Load
contacts                 chef, grandchecf, coupeurdetete
first_notification       3
last_notification        0
notification_interval    20
escalation_period        24×7
escalation_options       w,u,c,r
}

Cependant, cette forme de définition pose un problème : elle va s’appliquer sur des éléments, ici des services, au lieu d’être appelée par ces éléments.

Par clair? Disons qu’ici pour l’utiliser sur un service c’est sympa, mais en général on aimerait bien l’avoir pour un groupe de service, ou un groupe d’hôte, saufs certains service ou hôtes, etc. Bien sûr on a la possibilité de mettre * ou hostgroup_name, mais c’est vite limité. Bref, avoir la possibilité d’avoir une véritable gestion par des techniques d’héritages pourrait être utile (additif et implicite notamment).

De plus, quand on y pense, ici encore on a bien souvent un héritage host-> service non? Genre si la machine serveur-1 tombe, on aimerait bien avoir cette même règle sur les services de cette machine. Mais Nagios ne pospose ue serviceescalation et hostescalation, donc c’est pardu pour l”héritage, surtout quand c’est une application sur des éléments, et non un appel de ces éléments.

C’est pourquoi j’ai rajouté un nouvel object dans Shinken : escalation. Bah oui, ni service, ni host. Ca a un air de déjà vu pour la définition :

define escalation{
escalation_name        ToBoss
contacts                 chef, grandchecf, coupeurdetete
first_notification       3
last_notification        0
notification_interval    20
escalation_period        24×7
escalation_options       w,u,c,r
}

Et après on l’appel depuis un hôte :

define host{
[...]
escalations        ToBoss
[...]
}

Après si on ne défini rien sur les services de cet hôte, ce paramètre sera automatiquement hérité (TODO : rajouter une option pour hériter implicitement ou non certains champs). Et avec une telle définition, c’est ultra simple de le rajouter dans les templates qu’il faut, et hop, la gestion des escalade faciles. Ceci me permettra peut être de réellement les utiliser un jour, car dans leur état actuel, leur définition est un véritable cauchemars sur les grands environnements…

Gestion des exclusions de timeperiods

Posted in Shinken by Nap on January 6, 2010

Et bien après une bataille qui avait des air de guerre épique, j’ai mis en place les exclusions de timeperiods. Après une première version un peu … bourrine, une nouvelle arrive qui passe les tests et qui en plus est rapide. Cette partie du code n’est pas celle que je préfère, car il faut dire que les problèmes des dates et de calcul d’intervalle, c’est touffu, surtout lorsque l’intervalle ressemble à ‘monday 3 – thursday 4 00:00-11:00,12:00-24:00‘ (soit entre le troisième lundi du mois et le 4ième jeudi). Et puis le plus marrant dans ces définitions, c’est que c’est relatif par rapport au moment où vous calculer…

Mine de rien, c’est sûrement la partie la plus complexe de l’outil. Bon je ne vais pas me plaindre, le module time de python a bien aidé. Bref, vous pouvez faire une déclaration du genre :
define timeperiod{
timeperiod_name 24×7
alias 24_Hours_A_Day,_7_Days_A_Week
sunday 00:00-24:00
monday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
saturday 00:00-24:00
exclude workhours
}

# ‘workhours’ timeperiod definition
define timeperiod{
timeperiod_name workhours
alias Normal Work Hours
monday 09:00-17:00
tuesday 09:00-17:00
wednesday 09:00-17:00
thursday 09:00-17:00
friday 09:00-17:00
}

Donc ici 24×7 sera sans les workhours (bon bah c’est un exemple hein, à vous de trouver quelque chose de plus utile….). Donc un check en 24×7 voulant être lancé vers 10h le sera à 17h en fait. Ceci gère aussi si les timeperiods dans exclude ont elles même des exclude bien sûr.

Après MySQL, Oracle et couchdb : Sqlite

Posted in Shinken by Nap on January 4, 2010

Voici l’arrivée dans Shinken du support du schéma Merlin sous Sqlite (merci Python pour le support natif et simple). Sqlite permet d’avoir une base de données à peu de frais, directement dans un fichier, sans tout le bordel qu’il y a autour lorsque l’on souhaite une petite base simple en local.

Les applications tierces n’auront plus d’excuses pour encore utiliser les fichiers plats, là on fait du Select en un temps records, installation de la base comprise.

La configuration du plugin est simple :
define plugin{
plugin_name ToMerlindb_Sqlite
plugin_type merlindb_sqlite
database_path /data/mabase.sqlite
}

Généralisation des modulations de résultats

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

Comme vu dans des posts précédents, le fait de pouvoir changer des retours à la volée avant de les analyser peut être pratique, comme changer un critical en warning, ou bien un ok en critical. Sur la mailing list, Thomas Guyot-Sionnest a proposé de généraliser cela. C’est pourquoi je pense implémenter un nouvel objet dans Shinken (et oui, encore un :) ) : resultmodulation.

Ceci va ressembler à :

define resultmodulation{
resultmodulation_name     critical_is_warning           ;required
exit_codes_match                2                ;optionnal, list of code to change
output_match // ;optionnal, regexp for activation of exit_code if output match
exit_code_modulation       1                ;code that will be put if the code match
output_modulation              s///        ;optionnal regexp to change output
longoutput_modulation      s///      ;optionnal regexp to change long_output
modulation_period               24×7    ;period when to apply the modulation
}

Puis après dans les hôtes et service, on appelle le modulation, qui pourra être hérité de manière implicite:

define host{
[...]
resultmodulations critical_is_warning
}

On peut remarquer le s de resultmodulations. En effet, on peut avoir besoin de plusieurs modulations. Elles vont seulement être appliquées les unes à la suite des autres.

Il ne reste plus qu’à implémenter alors, et enlever les paramètres spécifiques comme hotperiod (dommage j’aimais bien ce nom :) )

Next Page »