Les escalades de notifications
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.
- 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é.
- 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é.
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.
Nous créerons un groupe Linux-Servers contenant les serveurs Linux.
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.
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.
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.
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.
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.
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
Dernière modification: 30/07/2023