Introduction

Ce type de fonctionnalité ne sera probablement pas utilisée par beaucoup d'entre vous. Quand elle est activée, elle permet d'enregistrer des changements dans le contrôle d'un service ou d'un hôte, même si l'état de celui-ci ne chenge pas. Nagios va alors surveiller plus particulièrement ce service ou cet hôte et enregistrer tout changement. Comme vous allez le constater, ceci peut être très utile plus tard, lors d'une analyse de vos journaux.

Comment cela marche t il ?

Dans des conditions de fonctionnement normales, le résultat de la surveillance d'un hôte ou d'un service n'est enregistré que lorsqu'il a changé d'état depuis le dernier contrôle. Il y a quelques exceptions à cette régle, mais c'est la plupart du temps comme cela que cela se passe.

Si vous activez ce type de contrôle pour un ou plusieurs états d'un hôte ou d'un service en particulier, Nagios enregistrera dans ses journaux toute différence entre le contrôle actuel et le précédent. examinez l'exemple suivant, sur 8 tests consécutifs d'un service :

Cette séquence étant donnée, vous devriez seulement voir deux entrées dans vos journaux, concernant cette catastrophe. La première arrivera à X+2 quand le service basculera de l'état OK à l'état WARNING. Le deuxième arrivera (trop tard), au moment du passage de WARNING à CRITICAL.

Vous pouriez avoir envie, pour une raison quelconque, d'avoir un historique complet de cet accident dans vos journaux. Peut être pour expliquer à votre patron comment tout cela est arrivé soudainement, ou aller vous en jeter un ou deux au bar du coin, pour en rire plutôt qu'en pleurer, ou encore ....

Ceci dit, si le suivi précis avait été activé pour les états CRITICAL, les états x+4 et x+5 logged auraient été enregistrés en plus de x+2 et x+3. Pourquoi ? parce que dans ce cas-là, Nagios aurait examiné les message émis pour vérifier s'ils différaient des précédents. Si le message émis change alors que l'état ne change pas, le message sera quand même enregistré.

Un exemple similaire peut être donné avec un service qui contrôle un serveur web. Si le plugin check_http retourne d'abord un WARNING sur une erreur 404, puis ensuite des WARNING à cause d'un modèle manquant sur la page, vous pouvez avoir envie de le savoir. Si vous n'avez pas activé le suivi précis, seul le premier WARNING (celui de l'erreur 404) sera enregistré dans les journaux et vous n'aurez aucune idée (en analysant les journaux) que les WARNING suivants ne sont pas dus à un erreur 405, mais plutôt à un modéle absent de la page web retournée.

Dois je activer le suivi précis?

Tout d'abord, vous devez décider si vous avez réellement besoin d'examiner vos logs pour trouver la cause d'un problème. Vous pouvez décider de l'activer pour quelques services ou hôtes, mais pas pour tous. Vous pouvez aussi décider que vous ne surveillerez que quelques états d'hôtes ou de services, mais pas tous. Par exemple, surveiller les états WARNING et CRITICAL d'un service, et pas les états OK ou UNKNOWN.

Cette décision dépend principalement du plugin que vous allez utiliser. Si le plugin retourne toujours le même texte/message pour un état particulier, il n'y a aucune raison de se fatiguer à activer ce type de contrôle.

Comment l'activer ?

Vous devez définir la directive stalking_options dans la définition des hôtes et services. Cette directive n'est supporté qu'avec des fichiers de configuration basé sur des modèles.

Inconvénients

Vous devez être conscients du fait qu'activer ce type de contrôle amène quelques inconvénients. Ils sont relatifs aux fonctions d'enregistrement trouvées dans les différents CGIs (histogramme, résumé des alertes, etc.). Comme le suivi précis va apporter des entrées supplémentaires dans les journaux, les données retournées montreront un accroissement sensible du nombre d'alertes.

D'une manière générale, je déconseille d'activer ce service sans avoir mené auparavant une réflexion profonde sur le sujet. Mais, bien entendu, c'est là pour servir si vous en avez besoin.