Chapitre 28. Les contrôles d'hôtes

Introduction

Le fonctionnement de base des contrôles d'hôtes est décrit ci-après…

Quand sont effectués les contrôles d'hôtes ?

Les hôtes sont contrôlés par le démon Nagios:

A intervalles réguliers, tel que défini par les options check_interval et retry_interval dans vos définitions d'hôtes .
A la demande quand un service associé avec l'hôte change d'état.
A la demande, au besoin dans le cadre de la logique accessibilité réseau de l'hôte .
Sur demande au besoin des contrôles en prévision des dépendances des hôtes .

Les contrôles d'hôtes planifiés régulièrement sont optionels. Si vous avez positionnez l'option check_interval à zéro (0), Nagios ne fera pas les contrôles d'hôtes de façon régulière. Il fera toutefois des contrôles des hôtes à la demande pour les besoins de la supervision.

Les contrôles à la demande sont effectués lorsqu'un service associé à l'hôte change d'état parce que Nagios a besoin de savoir si l'hôte a également changé d'état. Les services qui changent d'état sont souvent un indicateur du fait que l'hôte a peut-être aussi changé d'état. Par exemple, si Nagios détecte que le service HTTP associé avec un hôte vient juste de passer d'un état CRITICAL à un état OK, cela peut indiquer que l'hôte est redevenu à la normale et fonctionne suite à un redémarrage.

Les contrôles à la demande des hôtes sont aussi effectués dans le cadre de la logique d'accessibilité de l'hôte via le réseau. Nagios est conçu pour détecter les coupures réseau aussi rapidement que possible, en distinguant un état DOWN d'un état UNREACHABLE pour l'hôte. Ce sont deux états très différents et qui peuvent aider rapidement un adminuistrateur à localiser la l'origine de la coupure réseau.

Les contrôles à la demande peuvent aussi être effectués dans le cadre de la logique des contrôles en prévision des dépendances des hôtes . Ces contrôles permettent d'assurer que la logique de dépendance soit la plus précise que possible.

Les contrôles d'hôtes mis en cache

Les performances des contrôles d'hôtes à la demande peuvent être améliorées en implémenant l'utilisation des contrôles mis en cache, qui permettent à Nagios de ne pas exécuter un contrôle d'hôte s'il détermine qu'il a un résultat relativement récent à la place pour ce contrôle. Plus d'informations sur les contrôles mis en cache peuvent être trouvées ici.

Les contrôles et les dépendances

Vous pouvez définir des dépendances d'hôtes qui empêchent Nagios de contrôler le statut d'un hôte dépendant d'un service d'un ou plusieurs autres hôtes. Plus d'informations sur les dépendances peuvent être trouvées ici.

Parallélisation des contrôles d'hôtes

Les contrôles d'hôtes planifiés sont lancés en parallèle. Quand Nagios a besoin de procéder un un contrôle d'hôte planifié, il lancera le contrôle de l'hôte et reviendra à son travail initial (contrôle des services, etc.). Le contrôle de l'hôte est lancé dans un processus enfant qui a été dupliqué à partir du démon principal de Nagios. Quand le contrôle d'hôte est terminé, le processus enfant informe le processus Nagios principal (son parent) du résultat. Le processus principal de Nagios gère le résultat qu'il a reçu et prend les mesures appropriées (lancement des gestionnaires d'événements, envois des notifications, etc.).

Les contrôles à la demande sont également exécutés en parallèle si nécessaire. Comme mentionné précédement, Nagios peut renoncer à l'exécution d'un contrôle à la demande s'il peut utiliser un résultat relativement récent pour ce contrôle d'hôte.

Quand Nagios traite les résultats des contrôles d'hôtes planifiés ou à la demande, il peut lancer des contrôles (secondaires) sur d'autres hôtes. Ces contrôles peuvent être lancés pour deux raisons: les contrôles en prévision des dépendances des hôtes et pour déterminer le statut des hôtes qui utilisent la logique d'accessibilité réseau. Ces contrôles secondaires qui sont lancés sont généralement lancés en parallèle. Cependant, il y a une grosse exception dont vous devez être au courant, car elle peut avoir un effet négatif sur la performance…

Les hôtes qui ont leur variable max_check_attempts positionnée à 1 peuvent causer de sérieux problèmes de performance. La raison? Si Nagios a besoin de déterminer leur vrai état en utilisant la logique d'accessibilité réseau (pour voir s'ils sont DOWN ou UNREACHABLE), il va devoir lancer une série de contrôles sur tous ses hôtes parents immédiats. Juste pour rappel, ces contrôles sont exécutés en série, plutôt qu'en parallèle, du coup, cela peut causer un grosse baisse de performance. Pour cette raison, je vous recommande de toujours utiliser une valeur supérieure à 1 pour le paramètre max_check_attempts dans vos définitions d'hôtes.

Les états d'un hôte

Les hôtes qui sont contrôlés peuvent être dans un des trois états différents:

UP
DOWN
UNREACHABLE

Détermmination de l'état d'un hôte

Les contrôles d'hôtes sont réalisés par les plugins, qui retournent un état OK, WARNING, UNKNOWN, ou CRITICAL. Comment Nagios traduit-il le code de retour des plugins en états d'hôte UP, DOWN, ou UNREACHABLE? Voyons cela:

Le tableau ci-dessous montre à quoi correspondent les codes de retour des plugin en état d'hôte préalables. Certains post-traitement (qui sont décrits plus loin) sont fait et peuvent changer l'état final de l'hôte.

Résultat du Plugin	Etat préalable de l'Hôte
OK	UP
WARNING	UP ou DOWN*
UNKNOWN	DOWN
CRITICAL	DOWN

Les retours WARNING signifient généralement que l'hôte est UP. Cependant, les retours WARNING sont interprétés pour signifier que l'hôte est DOWN si l'option use_aggressive_host_checking est activée.

Si l'état de l'hôte préalable est DOWN, Nagios va essayer de voir s'il est réellement DOWN ou s'il est UNREACHABLE. La distinction entre les états d'hôtes DOWN et UNREACHABLE est important, car elle peut permettre aux admministrateurs de determiner l'origine de la coupure réseau rapidement. Le tableau suivant montre comment Nagios détermine l'état final en fonction de l'état de l'hôte(s) parent(s). Les parents d'hôtes sont définis dans le paramètre parents de la définition d'hôte.

Etat préalable de l'Hôte	Etat de l'Hôte Parent	Etat Final de l'Hôte
DOWN	Au moins un des parents est UP	DOWN
DOWN	Tous les parents sont soit DOWN soit UNREACHABLE	UNREACHABLE

Plus d'informations sur comment Nagios fait la différence entre les états DOWN et UNREACHABLE peuvent être trouvées ici.

Changements d'états d'un hôte

Comme vous êtes probablement conscients, les hôtes ne restent pas toujours dans un état. Des choses arrivent, des patches sont appliqués, et les serveurs ont besoins d'être redémarrés. Quand Nagios contrôle les statuts des hôtes, il sera capable de détecter quand un hôte a changé entre les états UP, DOWN, ou UNREACHABLE et prendra les mesures appropriées. Ces changements d'états se traduisent par différents types d'états (HARD or SOFT), qui peuvent déclencher les gestionnaires d'événements et l'envoi de notifications. Détecter et traiter les changements d'états, c'est le boulot de Nagios.

Quand les hôtes changent trop fréquement d'état, ils sont considérés comme étant flapping (oscillants). Un bon exemple d'oscillation d'un hôte serait un serveur qui redémarrerait spontanément lors du chargement du système d'exploitation. C'est toujours le scénario amusant à traiter. Nagios peut détecter lorsque l'hôte commence à osciller, et peut supprimer les notifications tant que les oscillations de l'état de l'hôte ne sont pas stabilisées. Plus d'informations sur la détection d'oscillation peuvent être trouvées ici.