Dépendances d'hôtes et de services

Introduction

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.

Aperçu des dépendances de services

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

Un service peut être dépendant d'un ou plusieurs autres services
Un service peut être dépendant de services qui ne sont pas associés au même hôte
Les dépendances de service ne se sont pas héritées (à moins que ce ne soit explicitement spécifié)
Les dépendances de service permettent de supprimer l'exécution de services et de notifications de service selon différents critères (états OK, WARNING, UNKNOWN, et/ou CRITICAL)

Définition de 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.

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
	}

Comment les dépendances d'un service sont testé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. 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 :

Nagios récupère l'état courant^* du service dont il dépend.
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é).
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.
Si l'état courant du service dont il dépend ne correspond à aucune des options d'échec de la dépendance, la dépendance est réputée avoir réussi et Nagios continuera avec la prochaine dépendance.

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.

Dépendances d'exécution

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).

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, 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).

Dépendances d'hôtes

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.