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…

Related Posts: