Chapitre 43. Détection et gestion de l'oscillation d'état

Introduction

Nagios supporte la détection optionnelle des hôtes et des services qui oscillent [NdT: ou bagotent]. L'oscillation intervient quand un service ou un hôte change d'état trop fréquemment, provoquant une tempête de notifications de problèmes et de rétablissement. L'oscillation peut être l'indice de problèmes de configuration (i.e. des seuils positionnés trop bas) ou de vrais problèmes sur le réseau.

Comment la détection d'oscillation fonctionne-t-elle ?

Avant d'aller plus loin, permettez-moi de signaler qu'implémenter la détection de l'oscillation a été assez difficile. Comment déterminer ce que trop fréquemment veut dire concernant les changements d'état de tel hôte ou service ? La première fois que je me suis penché sur la détection de l'oscillation, j'ai cherché des informations sur la façon dont on peut ou doit procéder. Voyant que je n'en trouvais pas, j'ai décidé de définir ce qui pourrait être une solution raisonnable. Les méthodes utilisées par Nagios pour détecter l'oscillation de l'état des hôtes et des services sont décrites ci-dessous…

Chaque fois qu'un contrôle de service résulte dans un état hard ou un état de rétablissement soft, Nagios contrôle si le service a commencé ou arrêté d'osciller.

Il le fait en stockant les 21 derniers résultats de contrôle de service dans un tableau. Les résultats les plus récents écrasent les anciens dans le tableau.
Le contenu du tableau d'historique des états est parcouru (depuis le plus ancien résultat jusqu'au plus récent) pour déterminer le pourcentage total de changements d'état survenus durant les 21 derniers contrôles du service.
En utilisant des pourcentages d'états de changements pour déterminer des changements états transitoires pour les hôtes et services
En comparant la valeur du pourcentage aux seuils d'oscillations inférieurs et supérieurs

Un hôte ou un service est déclaré comme oscillant lorsque son pourcentage dépasse la valeur du seuil supérieur d'oscillation.

Un hôte ou un service est déclaré comme normal lorsque son pourcentage est descendu en dessous de la valeur du seuil inférieur d'oscillation.

Exemple

Laissez vous décrire plus en détail le fonctionnement de la détection d'oscillation avec les services…

L'image suivante montre un tableau chronologique d'états de service. Les états OK sont en vert, les WARNING en jaune, les CRITICAL en rouge, et les UNKNOWN en orange. Des flèches bleues marquent les moments où des changements d'états sont survenus.

Le contenu du tableau d'historique des états est parcouru (depuis le plus ancien résultat jusqu'au plus récent) pour déterminer le pourcentage total de changements d'état survenus durant les 21 derniers contrôles du service. Un changement d'état survient quand un état archivé est différent de l'état archivé qui le précède immédiatement dans le tableau. Comme nous conservons les résultats des 21 derniers contrôles de service dans le tableau, il y a 20 changements d'état possibles.

La détection d'oscillation utilise une logique qui est basé sur un pourcentage de changement d'état pour le service. C'est une mesure de variation du service. Les services qui ne changent jamais d'état auront 0% de changement, quant aux services qui n'arrêteront pas de changer d'état, il approcheront du 100%. Bons nombres de services auront un pourcentage se situant entre ces 2 valeurs.

Il paraît évident que les changements d'état les plus récent ont plus de poids que les anciens, si bien qu'il nous faut recalculer le pourcentage total de changements d'état du service selon une espèce de courbe… Pour simplifier, j'ai décidé d'utiliser un rapport linéaire entre le temps et la pondération pour le calcul de ce pourcentage. Les fonctions de détection de l'oscillation sont conçues actuellement pour que le changement d'état le plus récent possible pèse 50% plus lourd que le plus ancien. L'image suivante montre combien le poids des changements d'état récents est supérieur à celui des anciens lors du calcul du pourcentage total de changements d'état d'un service particulier.

Prenons un rapide exemple de détection de l'oscillation. L'image ci-dessus montre le tableau d'historique des résultats de contrôle d'un service particulier. Les résultats les plus anciens sont à gauche et les plus récents à droite. Nous voyons dans cet exemple qu'il y a eu au total 7 changements d'état (en t3, t4, t5, t9, t12, t16, et t19). Sans pondération des changements d'état en fonction du temps, cela nous donnerait un total de 35% de changements d'état:

(7 changements d'état / un maximum possible de 20) * 100 = 35%

Quand on applique la pondération en fonction du moment d'apparition, le pourcentage est de moins de 35%. C'est logique dans la mesure où la plupart des changements d'états sont plutôt anciens. Disons que le pourcentage pondéré est finalement de 31%…

Ainsi donc, que signifient 31% de changements d'états ?

Hé bien, si le service n'oscillait pas auparavant et que 31% est supérieur ou égal à la valeur spécifiée par le paramètre high_service_flap_threshold de la définition du service, Nagios considère que le service vient de commencer à osciller.
Si le service oscillait auparavant et que 31% est inférieur ou égal à la valeur spécifiée par le paramètre low_service_flap_threshold de la définition du service, Nagios considère que le service vient de s'arrêter d'osciller.

Si aucune de ces deux conditions n'est remplie, Nagios ne fait rien de plus concernant le service, car soit il n'oscille pas, soit il oscille toujours…

Détection de l'oscillation pour les services

Nagios regarde si le service est en état d'oscillation avant d'exécuter un contrôle (actif comme passif).

Le principe pour la détection d'oscillation des services fonctionnent de la manière qu'expliqué ci-dessus.

Détection de l'oscillation d'hôte

La détection de l'oscillation d'hôte fonctionne de manière similaire à la détection d'oscillation de service, avec une différence importante : Nagios essaiera de déterminer: si un hôte oscille à chaque contrôle de l'état de l'hôte et à chaque contrôle d'un service associé à cet hôte.

Si un hôte est contrôlé (activement ou passivement)
L'oscillation d'un hôte sera contrôlée si son état a changé depuis la dernière détection d'oscillation de cet hôte ou si son état n'a pas changé, mais qu'au moins x temps s'est écoulé depuis la dernière détection d'oscillation. Ce temps est égal à la moyenne des intervalles de contrôles de tous les services associés avec l'hôte.

Pourquoi cela ? Hé bien, parce qu'avec les services, nous savons que l'intervalle minimal de temps entre deux détections d'oscillation consécutives sera égal à l'intervalle de contrôle du service. Avec les hôtes, nous n'avons pas d'intervalle de contrôle, du fait que les hôtes ne sont pas supervisés de manière régulière. Ils ne sont contrôlés que lorsque c'est nécessaire. C'est la meilleure méthode que j'ai pu imaginer pour déterminer la fréquence de la détection d'oscillation d'un hôte…

Seuils de détection de l'oscillation

Nagios utilise plusieurs variables pour déterminer le pourcentage de changement d'état attribué aux seuils de la détection d'oscillation. Tant pour les hôtes que pour les services, il y a des seuils supérieurs et inférieurs globaux et spécifiques que vous pouvez configurer. Nagios utilisera les seuils globaux par défaut si vous n'en spécifiez aucun.

Le tableau ci-dessous montre les variables globales et spécifiques pour les hôtes et services afin de gérer les seuils de détection.

Type d'objet	Variables Globales	Variables spécifiques aux objets
Hôte	`low_host_flap_threshold` `high_host_flap_threshold`	low_flap_threshold high_flap_threshold
Service	`low_service_flap_threshold` `high_service_flap_threshold`	low_flap_threshold high_flap_threshold

Les états utilisés pour la détection de l'oscillation

Normalement Nagios scrutera les résultats des 21 derniers contrôles d'un hôte ou d'un service, sans tenir compte du résultat de contrôle (état hôte / service), pour l'utilisation dans la logique de détection de l'oscillation.

Nous pouvons exclure certains hôtes ou services à l'algorithme de de l'oscillation en utilisant le paramètre flap_detection_options dans la définition de l'hôte ou du service. Cette option vous permet de préciser pour quel états d'hôte ou service (par exemple UP, DOWN, OK, CRITICAL) vous voulez utilisez la détection d'oscillation. Si vous n'utilisez pas ce paramètre, la règle par défaut sera appliquée pour tous.

Gestion de l'oscillation

Quand un service ou un hôte commence à osciller, Nagios :

journalise un message indiquant que le service ou l'hôte oscille.
ajoute un commentaire non persistant à l'hôte ou au service indiquant qu'il oscille.
envoie une notification de démarrage de l'état d'oscillation aux contacts.
supprime les notifications pour le service ou l'hôte concerné (c'est l'un des filtre de l'algorithme de notification)

Quand un service ou un hôte s'arrête d'osciller, Nagios :

journalise un message indiquant que le service ou l'hôte n'oscille plus.
supprime le commentaire qui avait été ajouté au service ou à l'hôte lorsqu'il avait commencé à osciller
envoie une notification de retour à l'état normal de l'hôte ou du service aux contacts.
lève le blocage des notifications sur le service ou l'hôte concerné (les notifications restant assujetties à l'algorithme de notification)

Activation de la détection d'oscillation

Dans l'ordre, pour activer la détection d'oscillation dans Nagios, il faut :

Passer le paramètre enable_flap_detection à 1
Passer le paramètre flap_detection_enabled dans la définition de votre hôte ou service à 1

Si vous voulez désactiver de manière générale cette option, passez le paramètre enable_flap_detection à 0.

Si vou voulez désactiver cette option pour quelques hôtes ou services, utilisez le paramètre flap_detection_enabled dans la définition de vos hôtes et services pour faire ça.