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         24x7 ;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 :) )

Jean Gabès