Introduction

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

  • Nous appelons notifications toutes manières d'informer les utilisateurs d'un statut ou d'un contexte.

Les commandes de notifications sont expliquées plus en détail sur la page Commandes de notification (création et personnalisation).

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 :

  1. Quand un statut change d'état et que ce changement est confirmé ( ce qu'on appelle l'état "Hard" ). 
  2. Quand un hôte ou un check entre dans un contexte particulier ( DOWNTIME, ACKNOWLEDGE, ou FLAPPING ), ou qu'il en sort, sauf ACKNOWLEDGE, qui n'est notifié qu'une fois.
    • Les notifications sont désactivées pendant la durée du contexte. 
    • Cela permet d'éviter de noyer l'information principale par celle des changements de statuts intermédiaires lors d'une maintenance ou d'un FLAPPING.

  3. Si l'élément possède une Escalade des notifications, elle peut être activée si l'élément est toujours non OK pendant un temps donné.

  4. Après un temps précisé dans l'intervalle de notification, une notification se répète si l'état de l'élément est toujours non OK ( par défaut, une journée ).

Par ailleurs, les notifications de reprise ne sont envoyées que si la notification de problème d'origine ( avertissement ou critique ) a été notifiée.


Notez que seuls les changements sont notifiés. Il est donc possible de ne pas recevoir de notification lorsqu'on les active sur un hôte ou un check qui est déjà en état "hard" non-OK, puisque cet état n'a pas encore changé.


Qui est notifié ?

Dans chaque définition d'hôte et de check, les paramètres "Les utilisateurs à notifier" et "Les groupes d'utilisateurs à notifier" précisent quels contacts doivent recevoir les notifications pour cet élément en particulier

  • Voir l'onglet de notification dans la page Créer un Hôte  et Créer un check.
  • Les clefs d'imports de ces propriétés sont respectivement "notification_contacts" et "notification_contact_groups".

Après application des filtres ( voir ci-dessous: Les filtres), pour chaque contact à notifier, le Reactionner lancera la commande de notification appropriée.

  • Cette commande est définie dans la Méthodes de notification.
  • La méthode de notification permet de choisir la commande envoyée et de configurer les filtres par type de notification et par période.


Pour chaque notification de problème envoyée, enverra une notification de reprise ( lorsque l'état redevient OK ) à tous les contacts précédemment notifiés, même si les paramètres ont entre-temps été modifiés.


Les filtres

Plusieurs mécanismes permettent de filtrer les notifications.

Ces filtres sont cumulatifs, et une notification doit donc respecter tous les critères de configuration avant d'être envoyée.

Filtre global

Les notifications peuvent être désactivées pour tout Shinken Entreprise

  • Aucune notification ne sera alors envoyée.
  • Cette activation/désactivation se fait dans le fichier Shinken.cfg, avec le paramètre enable_notifications ( voir Configuration avancée ( shinken.cfg ).

Filtre sur les hôtes/cluster/checks

Il est possible de désactiver les notifications envoyées sur l'élément ( hôtes, clusters, ou checks ) en lui-même, en utilisant la propriété "Notifications activées" ( clé d'import: notifications_enabled ).

  • Mettre cette option à 0, désactivera toute notification sur l'élément concerné.

Filtres sur les options de notification

La configuration spécifique des éléments ( hôtes, clusters, ou checks ) permet de déterminer si un type de notification donné est envoyé.

  • Il est possible de déterminer, par exemple, que seules les notifications de type état critique seront envoyées, et de désactiver donc les avertissements ( dans le cas des checks ), l'inconnu, le flapping, les maintenances et les reprises.
  • Ce filtre est également présent sur la méthode de notification.
  • Les options de notification doivent être autorisées à la fois par l'élément à l'origine de la notification et la méthode de notification.

Plus de précision que les options sur la page d'édition des méthodes de notification.

Filtre par période

Chaque définition d’élément ( hôtes, clusters, ou checks ) contient la propriété "Période de temps de notification" ( clé d'import : notification_period ) qui précise la période de validité pendant laquelle les notifications sont autorisées ( par ex, 8h-18h ).

  • En dehors de la période de notification, personne ne recevra de notification.
  • Lorsqu'un élément sort de sa période de notification, Shinken Enterprise va replanifier la prochaine notification pour l'élément dans la prochaine période de notification.
    Cela permet de garantir que les utilisateurs seront notifiés des problèmes dès que possible lorsque la prochaine période temps valide arrivera.

Ce filtre est également présent sur la méthode de notification et la période doit donc également correspondre.

Récapitulatif en visualisation

Les dernières notifications envoyées sont récapitulées sur l'élément en question, dans l'UI de Visualisation.

  • Dans le cas des checks, les notifications récentes sont disponibles dans un onglet du volet de détail du check.
  • Il est également possible de rechercher un contact particulier dans le but de connaître les notifications qu'il a effectivement reçues, après application des filtres.