Introduction

Nagios propose une fonctionnalité de vérification de la "fraîcheur" des résultats de contrôles d'hôtes et de services. Cette fonctionnalité est utile pour vous assurer que des contrôles passifs sont reçus à la fréquence que vous souhaitez. Bien que le contrôle de fraîcheur puisse être utilisé dans de nombreuses situations, son emploi premier est dans la configuration d'un environnement de supervision réparti.

Le but du contrôle de "fraîcheur" est de s'assurer que les contrôles d'hôte et de service sont soumis régulièrement de manière passive par des applications externes. Si les résultats d'un contrôle d'hôte ou de service (pour lequel vous avez activé le contrôle de fraîcheur) sont considérés comme "périmés", Nagios forcera un contrôle actif de l'hôte ou du service.

Contrôle de fraîcheur d'hôte ou de service

La documentation ci-dessous décrit le contrôle de fraîcheur de service. Le contrôle de fraîcheur d'hôte (qui n'est pas documenté individuellement) fonctionne de manière similaire au contrôle de fraîcheur de service - à part évidemment qu'il se rapporte à la fraîcheur des hôtes et pas à celle des services. Si vous souhaitez configurer le contrôle de fraîcheur d'hôte, adaptez les instructions ci-dessous.

Configuration du contrôle de fraîcheur de service

Avant de paramétrer le seuil de fraîcheur de chaque service, vous devez activer le contrôle de fraîcheur par les paramétres check_service_freshness et freshness_check_interval du fichier de configuration principal. Si vous deviez configurer le contrôle de fraîcheur d'hôte, vous utiliseriez les paramétres check_host_freshness et host_freshness_check_interval.

Maintenant, comment activer le contrôle de fraîcheur d'un service en particulier ? Vous devez configurer la définition de service comme suit.

• Le paramétre check_freshness de la définition du service doit valoir 1. Cela active le contrôle de "fraîcheur" du service.
• Le paramétre freshness_threshold de la définition du service doit avoir une valeur (en secondes) qui refléte quel "fraîcheur" les résultats de ce service doivent présenter.
• Le paramétre check_command de la définition du service doit être une commande valide, permettant de contrôler activement le service quand il est vu comme "périmé".
• Le paramétre normal_check_interval de la définition du service doit être supérieur à zéro (0) si le paramétre freshness_threshold vaut zéro (0).
• Le paramétre check_period de la définition du service doit être une période valide. L'intervalle de temps que spécifie la période détermine quand les contrôles de fraîcheur peuvent être exécutés pour le service.

Fonctionnement du seuil de fraîcheur

Nagios contrôle régulièrement la "fraîcheur" des résultats de tous les services dont le contrôle de fraîcheur est activé. Le paramétre freshness_threshold de la définition de chaque service permet de déterminer quelle "fraîcheur" ces résultats doivent présenter. Par exemple, si vous donnez la valeur 60 au paramétre freshness_threshold de l'un de vos services, Nagios considérera que le service est "périmé" si ses resultats sont âgés de plus de 60 secondes (1 minute). Si vous ne spécifiez pas de valeur pour le paramétre freshness_threshold (ou si vous le mettez à zéro), Nagios calculera automatiquement un seuil de "fraîcheur" à utiliser en se basant soit sur le paramétre normal_check_interval soit sur retry_check_interval (selon le type d'état dans lequel se trouve le service actuellement).

Ce qui se passe lorsqu'un résultat de contrôle de service devient "périmé"

Si le résultat d'un contrôle de service devient "périmé" (selon la définition ci-dessus), Nagios forcera un contrôle actif du service en exécutant la commande spécifiée par le paramétre check_command de la définition du service. Il est important de noter qu'un contrôle de service actif déclenché parce que le service est vu comme "périmé" sera exécuté même si les contrôles actifs de service sont désactivés de manière globale ou pour le service en particulier.

Travailler avec des contrôles purement passifs

Comme je l'ai déjà dit, le contrôle de fraîcheur est surtout utile pour les services dont les résultats sont issus d'un contrôle passif. Il se peut bien souvent (comme dans le cas d'une supervision répartie) que ces services ne reçoivent pas tous les résultats de leur contrôle passif - aucun résultat n'étant obtenu par contrôle actif.

Un exemple de service purement passif pourrait être un rapport d'état de vos travaux de sauvegarde de nuit. Vous avez peut-être un script externe qui soumet les résultats du travail de sauvegarde à Nagios une fois que la sauvegarde est terminée. Dans ce cas, tous les résultats des contrôles pour ce service sont fournis par une application externe, en utilisant des contrôles passifs. Pour vous assurer que l'état des travaux de sauvegarde est bien remonté chaque jour, vous activerez le contrôle de fraîcheur pour ce service. Si le script externe ne soumet pas les resultats du travail de sauvegarde, vous pouvez faire en sorte que Nagios simule un résultat "critical" de la manière suivante...

Voici ce à quoi la définition du service pourrait ressembler (certains paramétres obligatoires ont été omis)...

define service{
	host_name		backup-server
	service_description	ArcServe Backup Job
	active_checks_enabled	0			; active checks are NOT enabled
	passive_checks_enabled	1			; passive checks are enabled (this is how results are reported)
	check_freshness		1
	freshness_threshold	93600			; 26 hour threshold, since backups may not always finish at the same time
	check_command		no-backup-report	; this command is run only if the service results are "stale"
	...other options...
	}

Notez que les contrôles actifs sont désactivés pour ce service. En effet les résultats du service sont uniquement fournis par une application externe, en utilisant des contrôles passifs. Le contrôle de fraîcheur est activé et le seuil de fraîcheur a été positionné à 26 heures. C'est un peu plus de 24 heures parce que la durée des travaux de sauvegarde varie selon les jours (en fonction du volume de données à sauvegarder, de l'encombrement du réseau, etc.). La commande no-backup-report est exécutée seulement si les résultats du service sont considérés comme "périmés". La définition de la commande no-backup-report pourrait ressembler à ceci...

define command{
	command_name	no-backup-report
	command_line	/usr/local/nagios/libexec/nobackupreport.sh
	}

Le script nobackupreport.sh dans votre répertoire /usr/local/nagios/libexec pourait ressembler à ceci :

#!/bin/sh

/bin/echo "CRITICAL: Results of backup job were not reported!"

exit 2

Si Nagios détecte que les résultats du service sont périmés, il lancera la commande no-backup-report comme un contrôle actif de service (même si les contrôles actifs sont désactivés pour ce service - rappelez-vous que nous sommes dans un cas particulier). Cela lance le script /usr/local/nagios/libexec/nobackupreport.sh, qui retourne un état "critical". Le service passe en état "critical" (s'il n'y était pas déjà) et quelqu'un sera probablement notifié du problème.