Page History

Concept

Les notifications sont toutes les

Introduction

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

manières d'informer les utilisateurs ( ou groupe d'utilisateurs ) du changement 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).

d'un élément de supervision ( Hôte, cluster ou check ).

Les notifications doivent être configurées de manière précise pour :

• Ne pas louper des changements de statut essentiel
• Ne pas recevoir des mails pour tout sinon les informations importantes risque d'être dilué dans la masse
• Échelonner les utilisateurs à notifier en prenant en compte la durée, la persistance de l'arrêt du service.

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

Quand

?

La décision d’envoyer une notification est définie dans la politique de vérification.

Elles sont lancées dans les

situations suivantes :

1. Quand

1. le statut

1. d'

1. un élément change et que ce changement est confirmé ( ce qu'on appelle l'état "Hard" ). 
   • Confirmé veut dire qu'on a constaté un état non OK, plusieurs fois d'affilée :
     • Le nombre de constats nécessaires est paramétrable par éléments.
   • Plus d'informations sur l'état "

1. • Hard" sont disponibles dans la page

1. • Statut confirmé ( HARD ) et non confirmé ( SOFT ).
     
     
2. Quand un

1. élément entre dans un contexte particulier (

1. PERIODE DE MAINTENANCE, PRISE EN COMPTE, ou FLAPPING => voir la page Statut & Contexte ), ou qu'il en sort

1. , sauf

1. PERIODE DE MAINTENANCE, qui n'est notifié qu'une fois

1. .
   • Les notifications sont désactivées pendant la durée du contexte.

1. • 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.
     
     
2. Si l'élément possède une escalade ( voir page Escalade des notifications ), elle peut être activée si l'élément est toujours non OK

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

2 précisions :

• Il est possible que ces différentes situations n'émettent pas de notification en fonction des filtres définis ( Voir ci-dessous : Les filtres )
• Les

• notifications de reprise ne sont envoyées que si la notification de problème d'origine (

• AVERTISSEMENT ou

• CRITIQUE ) a été notifiée.

À qui ?

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

• Voir la section "Notifications" de l'onglet

Si un contact est présent soit dans le paramètre contact, ou appartient à un des groupes, il fera partie des contacts à notifier.

• "Droits de l'utilisateur" dans l'édition d'un hôte ( Voir la page Éditer un Hôte ) ou l'onglet "Notifications" dans l'édition d'un check ( voir la page Editer 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 )Après application des filtres, pour chaque contact à notifier, le le Reactionner lancera la commande de notification appropriée. appropriée ( voir la page Le Reactionner ).

• Cette commande est définie dans

• chaque méthode de notification ( voir la page Édition d'une méthode 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.

Les filtres

Anchor
Les_filtres 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 la page Configuration avancée ( shinken.cfg ).

Filtre sur les hôtes/cluster/checks

Activer/Désactiver les notifications

Il est possible de désactiver de manière globale les notifications envoyées , en utilisant le paramètre Notification Enabled dans la configuration de l'hôte ou du check.

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

Filtres sur les options de notification

sur l'élément ( hôtes, clusters, ou checks ) en lui-même :

• Dans l'UI de Configuration, en modifiant la propriété "Notifications activées" dans l'onglet "Notifications" de chaque élément ( Par exemple voir la page Éditer un Hôte ).
• Dans le format cfg des éléments, il faut utiliser la clé d'import : notifications_enabled.

N'émettre des notifications que sur certains états

La configuration des éléments ( hôtes, clusters, ou checks ) permet aussi La configuration spécifique des éléments sur un check ou un hôte 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 sur les CRITIQUES seront envoyées, et de désactiver donc les avertissements AVERTISSEMENTS ( dans le cas des checks ), l'inconnuINCONNU, le flappingFLAPPING, les maintenances PÉRIODES DE MAINTENANCES et les reprises .:

• Dans l'UI de Configuration, en modifiant la propriété "Options de notification" dans l'onglet "Notifications" de chaque élément ( Par exemple voir la page Éditer un Hôte ).
• Dans le format cfg des éléments, il faut utiliser la clé d'import : notification_options.

Seulement sur une 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

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'hôte et de check contient un paramètre Notification Period qui précise la période de validité pendant laquelle les notifications sont autorisées ( par ex, 8h-18h ). Si le temps ne correspond pas à

• 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 re-planifier la prochaine notification pour l'

• élément à l'entrée de 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

• .

Cela se configure :

• Dans l'UI de Configuration, en modifiant la propriété "Période de temps de notification" dans l'onglet "Notifications" de chaque élément ( Par exemple voir la page Éditer un Hôte ).
• Dans le format cfg des éléments, il faut utiliser la clé d'import : notification_period.

Avec un décalage de la première notification

Cela permet de définir combien de minutes, le Scheduler doit attendre, avant de créer la première notification.

• Ce temps additionnel peut être mis à profit par les utilisateurs pour prendre en compte l'hôte depuis l'Interface de Visualisation avant que la notification ne soit envoyée ( Mettre le contexte PRIS EN COMPTE ).

Filtres sur les méthodes de notifications

Activer/Désactiver les notifications

Vous pouvez choisir si une méthode de notification va envoyer des notifications pour les hôtes/clusters ET/OU les checks.

N'émettre des notifications que sur certains états

Pour les hôtes/clusters ET/OU les checks, il est possible de décider qu'une méthode notification n'enverra des notifications que pour certains types de STATUTS ou CONTEXTE.

• Il est possible de déterminer, par exemple, que seules les notifications sur les CRITIQUES seront envoyées, et de désactiver les AVERTISSEMENTS ( dans le cas des checks ), l'INCONNU, le FLAPPING, les PÉRIODES DE MAINTENANCES et les reprises.
• 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 d'une méthode de notification.

Seulement sur une période

Une période de notification peut être définie différemment pour les hôtes/clusters ET/OU les checks.

• Cela signifie que la méthode de notification n'exécutera la commande que si la période de notification indique qu'il faut émettre la notification.
• Plus de précision que les options sur la page d'Édition d'une méthode de notification.

En fonction de l'importance de l'élément

En fonction de l'importance définie sur un élément ( hôtes, cluster, checks ), la méthode de notification n'exécutera la commande que si l'importance est égale ou supérieure à celle paramétrée dans la méthode de notification.

• Plus de précision que les options sur la page d'Édition d'une méthode de notification.

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.