Contrôle de validité des résultats des tests de services

Introduction

Nagios offre le contrôle de la validité (la "fraîcheur") des résultats d'un test de service. Ce contrôle est très utile lorsque vous voulez être sûr que les contrôles passifs sont reçus aussi fréquemment que vous le désirez. Bien que ce test puisse être utilisé dans de nombreux cas, il est tout d'abord destiné aux configurations faisant appel à un environnement de surveillance distribué.

Le but de cette fonctionnalité est d'assurer que les contrôles de services sont bien fournis passivement par des applications externes, mais de manière très régulière. Si les résultats d'un service particulier ( pour lequel cette fonctionnalité a été activée) sont considérés par Nagios comme "figés", Nagios forcera alors un contrôle actif de ce service.

Configuration du contrôle de validité

Avant de configurer les seuils service par service, vous devez activer le contrôle avec les directives check_service_freshness et freshness_check_interval du fichier de configuration principal.

Donc, comment activer ceci pour un service spécifique? Vous ne pouvez le faire que si vous utilisez le fichier de configuration des objets basé sur des modèles. Si vous employez l'ancienne syntaxe, le fichier de configuration ne peut pas comprendre les directives concernant ce type de contrôle.

En supposant donc que vous utilisez le bon type de fichier de configuration, celui à base de modèles, vous devez configurer la définition des services comme suit.

Fonctionnement des seuils

Nagios vérifie régulièrement la validité des résultats pour tous les services pour lesquels ce contrôle a été activé. L'option freshness_threshold détermine l'âge maximal des données retournées par le service. Par exemple, si le seuil freshness_threshold est à 60 secondes pour un des services, Nagios considérera les résultats de ce service comme "figés" si les résultats ont plus de 60 secondes. Si vous ne définissez pas l'option freshness_threshold option (ou si vous la mettez à 0), Nagios calculera automatiquement une valeur par défaut à partir des options normal_check_interval ou retry_check_interval options (tout ceci dépendant également du type d'état dans lequel le service se trouve).

Que se passe t il quand des résultats sont "figés"

Quand les résultats d"un service sont considérés comme figés, Nagios va forcer un contrôle actif, en exécutant la comande spécifiée dans l'option check_command de la définition du service. Il est important de noter que ce type de contrôle actif, activé par des résultats "figés", est exécuté même si les contrôles de service actifs sont désactivés de manière globale au niveau de Nagios.

N'utiliser des contrôles passifs

Comme indiqué ultérieurement, le contrôle de validité n'est utile que dans le cas de services qui obtiennent leurs résultats à travers de contrôles passifs. Plus souvent qu'à leur tour ( comme c'est le cas dans une surveillance distribuée), ces services peuvent ne pas recevoir tous leurs résultats de contrôles passifs - il est à noter qu'aucun résultat n'est obtenu à partir de contrôles actifs.

Un bon exemple de service recevant des données uniquement de contrôles passifs serait celui qui donne le status de vos sauvegardes nocturnes. Peut être avez vous un script externe qui soumet les résultats de ces sauvegardes à Nagios, une fois qu'elles sont terminées. Dans ce cas, tous les contrôles et leurs résultats sont fournis par une application externe à travers un contrôle passif. De manière à être sûr que ce status est délivré chaque jour, il faudra activer le contrôle de validité sur ces données. Sile script externe ne soumet pas des données en temps voulu, vous pouvez indiquer à Nagios de vous envoyer une alerte critique. Voilà comment s'y prendre....

Voici à quoi la définition du service ressemblera ( quelques options requises sont omises, pour simplifier la présentation) 

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. C'est parce que les résultats pour le service sont fournis uniquement à travers un contrôle passif. Le contrôle de validité est activé et le seuil est fixé à 26 heures. C'est un peu plus long que 24 heures parce que les sauvegardes se décalent parfois dans le temps (en fonction du volume à sauvegarder, du traffic réseau, etc...). La commande no-backup-report est exécutée seulement si le service est considéré comme figé. La définition de la dommande no-backup-report devrait ressembler à ceci ... 

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

Le script nobackupreport.sh dans /usr/local/nagios/libexec est très simple et pourrait être: 

#!/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 figées, il va lancer la commande no-backup-report comme un contrôle actif ( même si les contrôles actifs sont désactivés spécifiquement pour ce service) command as an active service check - souvenez vous que c'est un cas particulier). Ceci provoque l'exécution de /usr/local/nagios/libexec/nobackupreport.sh qui retournera un état critique pour ce service. Une fois ce service dans un état critique, il est probable que quelqu'un va en être averti.