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…
L'escalade des notifications de service est effectuée en définissant les escalades de service dans votre fichier de configuration d'objet. Ces définitions sont utilisées pour que les notifications relatives à un service particulier escaladent.
L'escalade des notifications d'hôtes est effectuée en définissant les escalades d'hôtes dans votre fichier de configuration d'objets. Les exemples que je donne ci-dessous utilisent tous les définitions d'escalade de service, mais les escalades 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).
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 tous les exemples que j'utiliserai, je considèrerai que le groupe de contacts par défaut des définitions de service s'appelle nt-admins.
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 hautes". 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 est escaladé. 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 0
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 aient é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.
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 :
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é.
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.
Une 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 l'exemple ci-dessus, 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.
Dans des circonstances normales, les escalades peuvent servir aux heures où une notification pourrait normalement être envoyée pour le service. Cette "fenêtre d'heures de notification" est déterminée par la directive notification_period de la definition de service.
Vous pouvez optionnellement restreindre l'escalade pour qu'elle ne soit prise ne compte pendant une période de temps spécifique en utilisant la directive escalation_period dans la définition de l'escalade de service. Si vous utilisez la directive escalation_period pour spécifier une timeperiod pendant laquelle utiliser l'escalade, l'escalade sera prise en compte uniquement pendant ces heures. Si vous ne spécifiez aucune directive escalation_period, l'escalade peut être prise en compte à n'importe quelle heure pendant la "fenêtre d'heures de notification" pour le service.
Notez que la notification est toujours soumise aux restriction d'heure normales imposées par la directive notification_period de l'escalade de service, et donc que la période de temps que vous spécifiez dans l'escalade doit être comprise dans une plus grande "fenêtre d'heures de notification".
Si vous voulez restreindre la définition d'escalade pour qu'elle soit prise en compte uniquement quand le service est dans un état donné, vous pouves utiliser la directive escalation_options dans la définition de l'escalade de service. Si vous n'utilisez pas la directive escalation_options, l'escalade peut être prise en compte quel que soit l'état du service.