Vous êtes ici:

Menu


Stacks Image 24814
Les escalades de notifications permettent de modifier le comportement des notifications en cas d'anomalie. Elles permettent :
- de notifier des utilisateurs différents en fonction du nombre de notifications envoyées,
- de changer de moyens de notifications au cours du temps.
C'est la première option qui va être présentée dans cet article.

1 - Prérequis pour cet exemple

Tout d'abord, votre supervision doit être opérationnelle avec l'activation de la notification. La configuration des escalades de notification nécessite un peu de réflexion pour adapter la meilleure stratégie. En effet, ces escalades ne peuvent être globales mais peuvent affecter les différentes ressources ci-dessous :
- un ou plusieurs hôtes comprenant ou non les services associés,
- un ou plusieurs services,
- un ou plusieurs groupes d'hôtes comprenant ou non les services associés,
- un ou plusieurs groupes de services,
- un ou plusieurs méta-services.
Autre point d'attention, si une escalade de notifications est associée à une période de notifications en jours ouvrés, il n'y aura pas d'escalade de notification en dehors de cette période.

Pour notre exemple, nous aurons besoin d'un groupe de contacts operator et d'un groupe de contacts sysadmin. Nous allons affecter notre escalade au groupe d'hôtes Linux-Servers contenant tous les serveurs Linux.
Notre stratégie est la suivante, les trois premières notifications seront envoyées au groupe operator. Si aucun contact n'acquitte le service en défaut, la quatrième notification sera envoyée au groupe sysadmin. Il y aura donc une escalade. Le groupe operator ne recevra plus aucune notification d'alerte et de retour à la normale. Seul le groupe sysadmin sera concerné. Si aucun acquittement n'est appliqué, à la septième notification nous utiliserons la stratégie de notification par défaut du service, en général c'est le groupe supervisors qui sera concerné.
Stacks Image 240084
synoptique du fonctionnement
Il faut créer deux groupes de contacts grp_operator et grp_sysadmin qui contiendront respectivement les utilisateurs operator et sysadmin. Les escalades ne prennent en compte que les groupes de contacts.
Stacks Image 240122
Stacks Image 240119
Nous créerons un groupe Linux-Servers contenant les serveurs Linux.
Stacks Image 240125

2 - Configuration de l'escalade

Nous utiliserons deux escalades. Sélectionnons le menu Configuration > Notifications > Escalations. Cliquez sur Add pour créer la première escalade.
Stacks Image 240130
Escalade pour le groupe operator
Les intervalles de notifications sont réglés à une minute pour le test de vérification. Cliquez sur l'onglet Impacted Resources.
Stacks Image 240135
Escalade pour le groupe operator
Si l’option « Hostgroup inheritance to services » n’est pas cochée, les notifications pour les services sont ignorées. Sauvegardez. Ajoutez la deuxième escalade.
Stacks Image 240138
Les ressources impactées sont les mêmes que la notification operator. Sauvegardez et appliquez la configuration.

3 - test de notre escalade

Nous allons tester notre escalade. Provoquons une anomalie sur le service centreontrapd de notre serveur de supervision. Pour accélérer le fonctionnement, j'ai réglé les intervalles de vérification et notification à une minute. Il est facile de voir le fonctionnement des notifications en visualisant la page des logs dans la vue temps réels. Sélectionnez Monitoring > Event Logs. Sélectionnez le service concerné, cochez notifications et appliquez une période de trois heures.
Stacks Image 240051
premier test
Autre exemple, le service ayant été acquitté par le groupe sysadmin, lors du rétablissement du service à la normale, on constate que seul le groupe qui a acquitté est concerné par la notification recovery.
Stacks Image 240141
deuxième test
Ceci était un bref aperçu des escalades de notifications. Attention, ce paramétrage n'est pas pris en compte actuellement dans Clapi.

3 Références

comments powered by Disqus
 Vous êtes ici: