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

Related Posts:

Comments
  • Kry:

    Salut Nap!
    Je suis agréablement surpris de découvrir ton site! Je te félicite, il est très intéressant.
    Ce serait possible d’entrer en contacte avec toi pour discuter d’un petit projet ? (mon adresse mail est jointe au message)