Les dépendances d'hôtes et de services sont une fonctionnalité avancée qui vous permet de contrôler le comportement des hôtes et des services selon l'état d'un ou plusieurs autres hôtes ou services. Je vais expliquer comment les dépendances fonctionnent, ainsi que les différences entre les dépendances d'hôtes ou de services.

Il y a quelques points qu'il faut savoir concernant la dépendances de services:

Tout d'abord, les bases. Vous créez des dépendances de service en ajoutant des définitions de dépendance de service dans votre (vos) fichier(s) de configuration des objets .Dans chaque définition, vous spécifiez le service dépendant, le service dont il dépend, et la condition (s'il y a lieu) qui provoque l'échec des dépendances d'exécution et de notification (ces notions sont décrites plus loin).

Vous pouvez créer plusieurs dépendances pour un même service, mais il vous faut une définition de dépendance de service séparée pour chaque dépendance créée.

L'image suivante nous montre un exemple d'une trame typique de notification de service et d'exécution de ses dépendances. Différents services dépendent d'autres services pour que l'exécution des checks et des notifications se réalise.

Dans l'exemple ci-dessus, les définitions de dépendance du Service F sur l'hôte C seraient écrites comme ceci :

define servicedependency {
    host_name                       Host B
    service_description             Service D
    dependent_host_name             Host C
    dependent_service_description   Service F
    execution_failure_criteria      o
    notification_failure_criteria   w,u
}

define servicedependency {
    host_name                       Host B
    service_description             Service E
    dependent_host_name             Host C
    dependent_service_description   Service F
    execution_failure_criteria      n
    notification_failure_criteria   w,u,c
}

define servicedependency {
    host_name                       Host B
    service_description             Service C
    dependent_host_name             Host C
    dependent_service_description   Service F
    execution_failure_criteria      w
    notification_failure_criteria   c
}
        

Les autres définitions de dépendances décrites dans l'image précédente s'écriraient comme suit :

define servicedependency {
    host_name                       Host A
    service_description             Service A
    dependent_host_name             Host B
    dependent_service_description   Service D
    execution_failure_criteria      u
    notification_failure_criteria   n
}

define servicedependency {
    host_name                       Host A
    service_description             Service B
    dependent_host_name             Host B
    dependent_service_description   Service E
    execution_failure_criteria      w,u
    notification_failure_criteria   c
}

define servicedependency {
    host_name                       Host B
    service_description             Service C
    dependent_host_name             Host B
    dependent_service_description   Service E
    execution_failure_criteria      n
    notification_failure_criteria   w,u,c
}
        

Avant que Nagios n'exécute un contrôle de service ou n'envoie des notifications concernant un service, il vérifiera si le service comporte des dépendances. Si ce n'est pas le cas, le contrôle est exécuté ou la notification est envoyée comme en temps normal. Si le service a bien une ou plusieurs dépendances, Nagios vérifiera chacune de la manière suivante :

Ce cycle continue jusqu'à ce que toutes les dépendances du service aient été vérifiées, ou jusqu'à ce qu'une dépendance échoue.

Les dépendances d'exécution permettent de limiter les vérifications de service actives .Les vérifications de service passives ne sont pas affectées par les dépendances d'exécution.

Si tous les tests de dépendance d'exécution du service réussissent, Nagios exécute le contrôle du service comme à l'accoutumée. Si ne serait-ce qu'une dépendance d'exécution du service échoue, Nagios arrêtera temporairement l'exécution des contrôles pour ce service (dépendant). Par la suite, les tests des dépendances d'exécution du service vont réussir. Alors, Nagios recommencera les contrôles de ce service de manière normale. Pour plus d'informations sur l'algorithme d'ordonnancement des contrôles , lisez ceci.

Dans l'exemple ci-dessus, les dépendances d'exécution du Service E échoueraient si le Service B est dans un état WARNING ou UNKNOWN. Si c'était le cas, le contrôle de service ne serait pas réalisé et serait ordonnancé pour une future exécution (potentielle).

Si tous les tests de dépendance de notification du service réussissent, Nagios enverra les notifications pour ce service comme à l'accoutumée. Si, ne serait-ce qu'une dépendance de notification du service échoue, Nagios arrêtera temporairement l'émission de notifications pour ce service (dépendant). Plus tard, les tests des dépendances de notifications du service vont réussir. Alors, Nagios recommencera à envoyer des notifications pour ce service de manière normale. Pour plus d'informations sur l'algorithme de notification, lisez ceci.

Dans l'exemple ci-dessus, les dépendances de notification du Service F échoueraient si le Service C est dans un état CRITICAL, et/ou si le Service D est dans un état WARNING ou UNKNOWN, et/ou si le Service E est dans un état WARNING, UNKNOWN, ou CRITICAL. Si c'était le cas, les notifications pour ce service ne seraient pas envoyées.

Comme je l'ai déjà dit, par défaut les dépendances de service ne sont pas héritées. Dans l'exemple ci-dessus, vous pouvez voir que le Service F est dépendant du Service E. Toutefois, il n'hérite pas automatiquement des dépendances du Service E sur le Service B et le Service C. Pour rendre le Service F dépendant du Service C, nous avons dû ajouter une autre définition de dépendance. Il n'y a pas de définition de dépendance pour le Service B, donc le Service F n'est pas dépendant du Service B.

Si vous voulez rendre les dépendances de service héritables, utilisez le paramètre inherits_parent dans la définition de la dépendance du service .Quand ce paramètre est activé, il indique que la dépendance hérite des dépendances du service dont elle dépend (également appelé le service maître). En d'autres termes, si le service maître dépend d'autres services et qu'une de ces dépendances est en échec, la dépendance sera aussi en échec.

Dans l'exemple ci-dessus, imaginez que vous vouliez ajouter une nouvelle dépendance au service F qui le rende dépendant du service A. Vous pourriez créer une nouvelle définition de dépendance qui indique le service F comme le service dépendant et le service A comme le service maître (c'est-à-dire le service dont il est dépendant). Vous pourriez également modifier la définition de dépendance des services D et F de la manière suivante :

define servicedependency {
    host_name                       Host B
    service_description             Service D
    dependent_host_name             Host C
    dependent_service_description   Service F
    execution_failure_criteria      o
    notification_failure_criteria   n
    inherits_parent                 1
}
        

Comme le paramètre inherits_parent est activé, la dépendance entre les services A et D sera testée quand la dépendance entre les services F et D le sera.

Les dépendances peuvent avoir de multiples niveaux d'héritage. Si la définition de dépendance entre A et D avait le paramètre inherits_parent activé, et que le service A était dépendant d'un autre service (appelons-le service G), le service F serait dépendant des services D, A, et G (et le serait potentiellement avec chacun selon des critères différents).

Comme vous vous y attendez probablement, les dépendances d'hôtes fonctionnent d'une manière similaire à celles de services. La principale différence est que ce sont des hôtes et pas des services. Une autre différence est que la dépendance d'hôte ne sert qu'à supprimer des notifications d'hôtes et non pas des controles d'hôtes.

Les bases de ce qu'il faut savoir sur les dépendances d'hôtes:

L'image suivante nous montre une trame de l'acheminement logique des dépendances de notifications d'hôtes.

Dans l'image ci-dessus, les définitions de dépendances pour l'hôte C devraient être définies ainsi:

define hostdependency {
    host_name                       Host A
    dependent_host_name             Host C
    notification_failure_criteria   d
}

define hostdependency {
    host_name                       Host B
    dependent_host_name             Host C
    notification_failure_criteria   d,u
}
        

Comme pour les dépendances de services, les dépendances d'hôtes ne sont pas héritées. Dans l'exemple de cette image, vous pouvez voir que l'hôte C n'hérite pas des dépendances de l'hôte B. Pour que C soit dépendant de A, une autre définition d'hôte doit être précisée.

Les dépendances de notifications d'hôtes marchent d'une manière similaire à celles de services. Si toutes les notifications de dépendance d'un hôte réussissent, Nagios enverra les notifications comme à l'accoutumée. Si ne serait-ce qu'une de ces dépendances échoue, Nagios supprimera temporairement toutes les notifications pour cet hôte (dépendant). Par la suite, les dépendances réussiront à nouveau. Nagios recommencera alors à envoyer les notifications de manière habituelle. Vous trouverez ici plus d'informations sur la l'algorithme de notification.