Concept

Les notifications permettent d'informer les utilisateurs en dehors de l'interface de Shinken d'un changement de statut ou de contexte d'un hôte, check ou cluster.

• Pour un élément donné ( hôte, check, cluster ), 
  • une notification sera générée, suivant la configuration de l'élément ( notifie sur tous les statuts et contextes, seulement sur certains, ... )
  • et l'envoyer à des utilisateurs en fonction du paramétrage de la ou les méthodes de notification qu'il utilise.

Les sous-pages vont expliquer :

• La logique de notification, c.a.d le "quand, qui, comment"  ( voir la page  Logique de notification ),
• Les types de notifications possibles :
  • Soit utiliser/customiser les notifications par email fourni par défaut dans Shinken ( voir la page  Utilisation des méthodes de notifications MAIL livrées par Shinken ).
  • Comment faire votre propre méthode de notification.
• Les escalades pour notifier d'autres utilisateurs si un élément est trop longtemps non OK par exemple ( voir la page Escalade des notifications  )

Mécanisme des notifications

Il est important de comprendre le mécanisme des notifications :

• C'est le Scheduler détermine si une notification doit avoir lieu, en créant des commandes de notification à exécuter 
• mais c'est le Reactionner qui exécute les scripts de notification, en prenant en charge les commandes de notification à exécuter.

Plus précisément, suivant le changement d'état d'un élément ( constaté par le Poller ), et la configuration définie sur cet élément, le Scheduler prépare les commandes pour notifier les utilisateurs de leur méthode de notification.

• Si pour un même utilisateur, plusieurs méthodes de notification sont définies, une commande de notification pourra être créée ( mais pas systématiquement, car cela dépendra du paramétrage de la méthode de notification ).
• Ceci permet d'avoir par exemple :
  • des doubles notifications,
  • ou de n'avoir qu'une notification, mais de changer de média en fonction de l'heure.