Logique de notification

Introduction

Ce chapitre explique en détail quand et comment sont envoyées les notifications, ainsi que les contacts concernés. 

L'escalade des notifications sera expliquée dans une autre page. 

Quand s'opèrent les notifications ?

La décision d’envoyer une notification est définie dans la politique de vérification. Elles sont lancées dans les cas suivants : 

• quand un état "hard" change . Plus d'informations sur le statut "hard" sont disponibles dans la page "état"  

• quand un hôte ou un check reste en état non-OK state et que le temps précisé dans le paramètre "notification_interval" dans la définition de l'hôte ou du check est dépassé depuis l'envoi de la dernière notification . 

Qui est notifié ?

Dans chaque définition d'hôte et de check, il y a un paramètre "contact groups" et "contacts", qui précise quels contacts doivent recevoir les notifications pour cet hôte en particulier. 

Quand Shinken Enterprise envoie une notification, il prévient chaque contact ou membre du groupe défini. Si un contact appartient à plusieurs groupes, il supprime les doublons avant envoi de la notification. 

Quels filtres adoptés pour envoyer des notifications

Ce n'est pas juste parce qu'il faut envoyer la notification que des contacts vont être avertis . Il y a plusieurs filtres qu'une notification doit traverser avant qu'elle ne soit jugée suffisamment digne d'être envoyée. Même là, des contacts peuvent ne pas la recevoir si leurs filtres de notifications ne permettent pas la notification. 

Program-Wide Filter:

Le 1er filtre que les notifications doivent passer est un test permettant de vérifier que celles-ci sont autorisées à un niveau global. Cette étape est définie par le paramètre  :ref:`"enable_notifications" <configuration/configmain-advanced#enable_notifications>` dans le fichier principal de configuration, (il peut être changé en cours d'utilisation dans l'interface web) . Si les notifications sont désactivées à un niveau global, aucune notification sur un hôte ou un check ne sera envoyée. Si elles sont activées au niveau global, d'autres filtres restent à passer. 

Filtres sur les hôtes et les check :

Le 1er filtre à appliquer est de vérifier si l'élément n'est pas sous maintenance. Si c'est le cas, personne n'est notifié. Si ce n'est pas le cas, il passe au filtre suivant.

Le second filtre est de vérifier si l'élément n'est pas en état "flapping" (si la détection est activée). Si c'est le cas, personne n'est notifié. Si ce n'est pas le cas, il passe au filtre suivant.

Le 3ème filtre est de vérifier si il n'y a pas d'options spécifiques sur l’élément. Chaque définition de check contient des options qui déterminent si les notifications peuvent être envoyées en fonction de l'état "warning" ou "critical", ou de la reprise. De la même façon, chaque définition d'hôte contient des options qui déterminent si les notifications sont envoyées lorsque l'élément tombe, devient injoignable ou retrouve son état. Si la notification ne passe pas ces filtres, aucune notification n'est envoyée. Sinon, elle passe au filtre suivant. 

Les notifications de retour à un état normal ne sont envoyées que lorsqu'une notification a déjà été envoyée sur le problème d'origine. Cela n'aurait pas de sens d'avertir sur un retour à la normale alors qu'on était pas informé d'un incident...  

Le 4ème filtre est de vérifier la période de test. Chaque définition d'hôte et de check contient un paramètre "notification_period" qui précise la période de validité. Si le temps ne correspond pas à la période valide, personne n'est contacté. Sinon, elle passe au filtre suivant.  

Si le passage du filtre de période n'est pas réussi, Shinken Enterprise va replanifier la prochaine notification pour l'hôte ou le check  (si il est dans un état non-OK ) dans la période temps valide. Cela permet de garantir que les contacts seront notifiés des problèmes dès que possible lorsque la prochaine période temps valide arrivera. 

Les derniers filtres sont conditionnés par 2 choses :  (1) une notification a déjà été envoyée sur un problème avec l'hôte ou le check dans le passé et (2) l'hôte ou le check est toujours dans le même état non-OK que celui dans lequel il était au moment de l'envoi de la dernière notification. Si ces 2 critères sont remplis, alors Shinken Enterprise vérifiera et s'assurera que le temps écoulé depuis la dernière notification est supérieur ou égal à la valeur spécifiée par l'option " notification_interval " dans la définition de  l'hôte ou du check . Si pas assez de temps s'est écoulé depuis la dernière notification, personne n'est contacté. Si un temps suffisant s'est écoulé depuis la dernière notification ou les deux critères de ce filtre n'ont pas été réunis, la notification sera envoyée ! 

Filtres sur les contacts:

A ce stade, la notification a passé le programme de filtre et Shinken Enterprise commence à notifier les personnes concernées. Cela veut-il dire que chaque contact va recevoir une notification ? Non ! Chaque contact a ses propres filtres que les notifications doivent également passer avant qu'elles soient reçues.  

Les filtres sont spécifiques à chaque contact .

Le 1er filtre qui doit être passé pour chaque contact concerne les options de notification. Chaque définition de contact contient des options qui déterminent si les notifications peuvent être envoyées en fonction de l'état "warning" ou "critical", ou de la reprise. De la même façon, chaque définition d'hôte contient des options qui déterminent si les notifications sont envoyées lorsque l'élément tombe, devient injoignable ou retrouve son état. Si la notification ne passe pas ces filtres, aucune notification n'est envoyée. Sinon, elle passe au filtre suivant  

Les notifications de retour à un état normal ne sont envoyées que lorsqu'une notification a déjà été envoyée sur le problème d'origine. Cela n'aurait pas de sens d'avertir sur un retour à la normale alors qu'on était pas informé d'un incident...  

Le 2ème filtre est de vérifier la période de test. Chaque définition de contact contient un paramètre "notification_period" qui précise la période de validité. Si le temps ne correspond pas à la période valide, personne n'est contacté. Sinon, le contact est notifié ! 

Méthodes de notification 

Shinken Enterprise est capable de notifier sur un problème ou un retour à la normale sur tout type de support : pager, mobile, email, SMS, message audio , etc. La façon dont elles sont envoyées dépend de la commande définie dans le fichier de définition de l'objet. 

Il existe déjà de nombreuses solutions externes prenant en main le gestion de ces notifications. Il suffit d'utiliser des packages disponibles supportant les mobiles, SMS....(simple script ou système complet de gestion) 

Type de macro de notification 

En créant votre commande de notification, il faut prendre en compte quel type de notification sera lancé. La macro $NOTIFICATIONTYPE$ contient une chaîne de caractère qui l'identifie précisément. Ci-joint une table avec les valeurs possibles et leurs descriptions :