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 pour les notifications d'hôtes et de services est possible par la création de définition d'escalations d'hôtes et de d'escalations de services dans votre Object Configuration Overview .

Les notifications sont échelonnées si et seulement si une ou plusieurs définitions d'escalade correspondent à la notification actuelle qui est envoyée. Si la notification de service ou d'un hôte n'a pas de définitions d'escalade valides qui s'y applique, le(s) groupe(s) de contact spécifié dans le groupe d'hôte ou dans la définition de service sera appliqué par défaut. 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.

En définissant des escalades de notification, il est important d'être conscient que n'importe quels groupes de contact qui étaient des membres de plus bas niveaux d'escalades (c'est-à-dire ceux avec les nombres de notification plus basses) devraient aussi être inclus dans les niveaux plus haut des définitions d'escalade. Cela devrait être fait pour garantir que quelqu'un qui est notifié d'un problème continue à suivre ce problème jusqu'à sa résolution. 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      3
    last_notification       5
    notification_interval   45
    contact_groups          nt-admins,managers
}
        

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 le paramètre notification_period de la définition de service. Notez que la notification est toujours soumise aux restrictions d'heure normales imposées par le paramètre 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.

Vous pouvez optionnellement restreindre l'escalade pour qu'elle ne soit prise ne compte pendant une période de temps spécifique en utilisant le paramètre escalation_period dans la définition de l'escalade de service. Si vous utilisez le paramètre escalation_period pour spécifier une Time Period Definition pendant laquelle utiliser l'escalade, l'escalade sera prise en compte uniquement pendant ces heures. Si vous ne spécifiez aucun paramètre escalation_period, l'escalade peut être prise en compte à n'importe quelle heure pendant la fenêtre d'heures de notification pour le service.

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 pouvez utiliser le paramètre escalation_options dans la définition de l'escalade de service. Si vous n'utilisez pas le paramètre escalation_options, l'escalade peut être prise en compte quel que soit l'état du service.