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

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

Jean Gabès