L'escalade des notifications


Introduction

Nagios supporte l'escalade optionelle des notifications envoyées aux contacts pour des services ou hôtes. Je vais en expliquer rapidement le fonctionnement, bien que cela se comprenne facilement...

Les escalades des notifications de service

L'escalade des notifications de service est effectuée en remplissant les définitions d'escalade de service dans le fichier de configuration d'hôte. Ces définitions sont utilisées pour que les notifications relatives à un service particulier escaladent.

Les escalades des notifications d'hôtes

L'escalade des notifications d'hôtes est effectuée en remplissant les définitions d'escalade d'hôtes ou de groupe d'hôtes dans le fichier de configuration d'hôtes. Ces définitions d'hôtes sont utilisées pour escalader les notifications d'hôtes spécifiques, alors que les définitions de groupes d'hôtes sont utilisées pour escalader les notifications de tous les hôtes d'un groupe particulier. Les exemples que je donne ci-dessous utilisent tous les définitions d'escalade de service, mais les escalades de groupes d'hôtes fonctionnent de la même manière (à l'exception du fait qu'elles sont utilisées pour les notifications d'hôtes et non de services).

Quand y a-t-il escalade des notifications?

Cette escalade a lieu si et seulement si au moins une définition d'escalade correspond à la notification qui est envoyée. Si à une notification d'hôte ou de service ne s'applique aucune définition d'escalade valide, le groupe de contacts précisé soit dans le groupe d'hôte ou de service sera utilisé pour la notification. Regardons l'exemple ci-dessous :

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	3
	last_notification	5
	notification_interval	90
	contact_groups		nt-admins,managers
	}

define serviceescalation{ host_name webserver service_description HTTP first_notification 6 last_notification 10 notification_interval 60 contact_groups nt-admins,managers,everyone }

Remarquez qu'il y a des "trous" dans les définitions d'escalade de notification. En particulier, les notifications 1 et 2 ne sont pas prises en compte par les escalades, ni celles au-delà de 10. Pour la première et la seconde notification, de même que pour celles au-delà de la dixième, le groupe de contacts par défaut précisé dans la définition de service est utilisé. Dans l'exemple ci-dessus, cela signifie que le groupe de contacts nt-admins serait le seul à recevoir ces notifications correspondant aux "trous".

Groupes de contact

Lorsqu'on définit les escalades de notification, il est important de garder à l'esprit que tous les groupes de contact qui appartenaient aux escalades "plus basses" (i.e celles avec les plus bas numéros de notification) doivent aussi être inclus dans les définitions d'escalade "plus grandes". Cela doit être effectué pour s'assurer que ceux qui se voient notifier un problème continuent de recevoir les notifications lorsque le problème prend de l'importance. Exemple :

define serviceescalation{
  	host_name webserver
  	service_description HTTP
  	first_notification 3
 	last_notification 5
 	notification_interval 90
  	contact_groups nt-admins,managers
  }


define serviceescalation{
  	host_name webserver
  	service_description HTTP
  	first_notification 6
  	last_notification 10
  	notification_interval 60
  	contact_groups nt-admins,managers,everyone
  }

Le premier (ou "plus bas") niveau d'escalade comprend à la fois les groupes de contact nt-admins et managers. Le dernier (ou "plus haut") niveau d'escalade comprend les groupes de contact nt-admins, managers, et everyone. Remarquez que le groupe de contact nt-admins fait partie des deux définitions d'escalade. C'est pour qu'il continue à être prévenu s'il reste des problèmes après que les deux premières notifications de service ont été envoyées. Le groupe de contact managers apparaît d'abord dans la définition d'escalade la "plus basse" - il reçoit sa première notification lorsque la troisième notification de problème est envoyée. Nous voulons que le groupe managers continue de recevoir des notifications si le problème persiste après cinq notifications, il fait donc partie de la "plus haute" définition d'escalade.

Recoupement des portées des escalades

Les définitions d'escalade de notification peuvent avoir des portées qui se recoupent. Prenons l'exemple suivant :

define serviceescalation{
  	host_name webserver
  	service_description HTTP
  	first_notification 3
 	last_notification 5
 	notification_interval 20
  	contact_groups nt-admins,managers
  }


define serviceescalation{
  	host_name webserver
  	service_description HTTP
  	first_notification 4
  	last_notification 0
  	notification_interval 30
  	contact_groups on-call-support
  }

Dans l'exemple ci-dessus :

Notifications de reprise d'activité

Les notifications de reprise d'activité sont légèrement différentes des notifications de problème lorsqu'il s'agit d'escalade. Prenons l'exemple suivant :

define serviceescalation{
  	host_name webserver
  	service_description HTTP
  	first_notification 3
 	last_notification 5
 	notification_interval 20
  	contact_groups nt-admins,managers
  }


define serviceescalation{
  	host_name webserver
  	service_description HTTP
  	first_notification 4
  	last_notification 0
  	notification_interval 30
  	contact_groups on-call-support
  }

Si, après trois notifications de problème, une notification de reprise d'activité est envoyée au service, qui reçoit la notification ? La reprise d'activité est la quatrième notification envoyée. Cependant, le code d'escalade est suffisamment bien fait pour que seules les personnes qui ont reçu la troisième notification reçoivent celle de reprise d'activité. Dans ce cas, les groupes de contact nt-admins et managers recevront la notification de reprise d'activité.

Intervalles de notification

Vous pouvez modifier la fréquence à laquelle les notifications escaladées sont émises pour un hôte ou un service particulier en utilisant le paramétre notification_interval de la définition d'escalade de groupe d'hôtes ou de service. Par exemple :

define serviceescalation{
  	host_name webserver
  	service_description HTTP
  	first_notification 3
 	last_notification 5
 	notification_interval 45
  	contact_groups nt-admins,managers
  }


define serviceescalation{
  	host_name webserver
  	service_description HTTP
  	first_notification 6
  	last_notification 0
  	notification_interval 60
  	contact_groups nt-admins,managers,everyone
  }

Dans cet exemple nous voyons que l'intervalle de notification par défaut pour les services est de 240 minutes (c'est la valeur donnée dans la définition du service). Quand la notification de ce service est escaladée lors des 3ème, 4ème, et 5ème notifications, un intervalle de 45 minutes sera utilisé entre les notifications. Lors de la 6ème notification et des suivantes, l'intervalle de notification sera de 60 minutes, comme il est spécifié dans la seconde définition d'escalade.

Comme il est possible d'avoir des définitions d'escalade qui se chevauchent pour un groupe d'hôtes ou un service donné, et comme un hôte peut être membre de plusieurs groupes d'hôtes, Nagios doit décider quel intervalle de notification utiliser quand des définitions d'escalade se chevauchent. Dans tous les cas de chevauchement, Nagios choisira l'intervalle de notification le plus court. Prenez l'exemple suvant :

define serviceescalation{
  	host_name webserver
  	service_description HTTP
  	first_notification 3
 	last_notification 5
 	notification_interval 45
  	contact_groups nt-admins,managers
  }


define serviceescalation{
  	host_name webserver
  	service_description HTTP
  	first_notification 4
  	last_notification 0
  	notification_interval 60
  	contact_groups nt-admins,managers,everyone
  }

Nous voyons que les deux définitions d'escalade se chevauchent sur les 4ème et 5ème notifications. Pour ces notifications, Nagios utilisera un intervalle de notification de 45 minutes, car c'est le plus petit intervalle présent dans les définitions d'escalade valides de ces notifications.

La dernière remarque à propos des intervalles de notification concerne les intervalles de 0. Un intervalle de 0 signifie que Nagios ne doit émettre une notification que pour la première notification valide durant cette définition d'escalade. Toutes les notifications suivantes pour le groupe d'hôte ou le service seront supprimées. Prenez cet exemple :

define serviceescalation{
  	host_name webserver
  	service_description HTTP
  	first_notification 3
 	last_notification 5
 	notification_interval 45
  	contact_groups nt-admins,managers
  }


define serviceescalation{
  	host_name webserver
  	service_description HTTP
  	first_notification 4
  	last_notification 6
  	notification_interval 0
  	contact_groups nt-admins,managers,everyone
  }

define serviceescalation{
  	host_name webserver
  	service_description HTTP
  	first_notification 7
  	last_notification 0
  	notification_interval 30
  	contact_groups nt-admins,managers
  }

Dans cet exemple, il y aurait au maximum 4 notifications de problème envoyées à propos du service. Ceci est dû au fait que l'intervalle de notification de 0 dans la seconde définition d'escalade indique qu'une seule notification doit être émise (à partir de et en incluant la 4ème notification) et que toutes les notifications suivantes doivent être supprimées. A cause de cela, la troisième définition d'escalade du service est sans effet, car il n'y aura jamais plus de quatre notifications.