Introduction

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

Aperçu

L'image ci-dessous montre un exemple de diagramme de dépendances de service. Voici quelques points à noter :

1. Un service peut être dépendant d'un ou plusieurs autres services
2. Un service peut être dépendant de services qui ne sont pas associés au même hôte
3. Les dépendances de service ne se sont pas héritées
4. Les dépendances de service peuvent provoquer l'échec de l'exécution de service et de notifications de service dans différentes circonstances (états OK, WARNING, UNKNOWN, et/ou CRITICAL)

Definition de dépendances de service

Tout d'abord, les bases. Vous créez des dépendances de service en ajoutant des définitions dependances 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 vous dépendez, et la condition (si elle existe) 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 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 n

}

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

}

Comment les dépendances de service sont vérifiées

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. S'il n'en a pas, 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 :

1. Nagios récupère l'état courant^* du service dont il dépend.
2. Nagios compare l'état courant du service dont il dépend aux options d'échec soit d'exécution soit de notification dans la définition de dépendance (selon ce qui adapté).
3. Si l'état courant du service dont il dépend correspond à une des options d'échec, la dépendance est réputée avoir échoué et Nagios sortira de la boucle de vérification des dépendances.
4. Si l'état courant du service dont il dépend ne correspond à aucune des options d'échec de la dépendance, la dépendance is réputée avoir réussi et Nagios continuera avec la prochaine dépendance.

Ce cycle continue jusqu'à ce que soit toutes les dépendances du service aient été vérifiées, soit 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 est dépendu 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.

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). Plus tard, 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 le contrôle serait ordonnancé pour une future exécution (potentielle).

Dépendances de notification

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.

Héritage de dépendance

Comme je l'ai déjà dit, 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. Dans certains cas, cette absence d'héritage implique l'ajout de définitions de dépendances dans votre fichier de configuration, mais je pense que cela rend les choses plus souples. Ainsi, dans l'exemple ci-dessus, nous pourrions avoir de bonnes raisons de ne pas rendre le Service F dépendant du Service B. Si les dépendances étaient automatiquement héritées, cela serait impossible.

Dépendances des hôtes

Comme vous l'attendez probablement, les dépendances d'hôtes marchent d'une manière similaire à celles de services. La grosse 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.

L'image ci dessous montre un dessin de la logique des 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 service, 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 definition d'hôte doit être définie.

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'une hôte passent, Nagios enverra les notifications comme normalement. Si seulement l'une de ces dépendances échoue, Nagios supprimera temporairement toutes notifications pour cet hôte. A un moment donné, dans le futur, les dépendances passeront à nouveau. Nagios recommencera alors à envoyer les notifications comme normalement. Plus d'informations peuvent etre trouvées là.