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.
L'image ci-dessous montre un exemple de diagramme de dépendances de services. Voici quelques points à noter :
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.
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.
*Il est important de noter que par défaut, Nagios utilisera l'état hard courant du (des) service(s) dont il dépend lors de ses vérifications de dépendance. Si vous voulez que Nagios utilise l'état le plus récent des services (que ce soit un état soft ou hard), activez l'option soft_service_dependencies.
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.
ATTENTION ! Ne confondez pas les dépendance d'hôtes avec les relations parent/enfant. Vous utiliserez les relations parent/enfant (définies avec le paramètre parents dans la définition d'hôte) dans la plupart des cas, plutôt que des dépendances d'hôtes.
L'image ci-dessous est un exemple de diagramme logique de dépendances 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.
NOTE : Les dépendances d'exécution d'hôtes fonctionnent de la même manière que les dépendances d'éxécution de services. Toutefois, elle ne sont prises en compte que lors des contrôles d'hôte ordonnancés régulièrement. Les contrôles d'hôtes à la demande ne sont pas concernés par les dépendances d'hôtes.