Gestionnaires d'évènements


Introduction

Les gestionnaires d'évènements sont des commandes optionnelles qui sont exécutées à chaque fois qu'un changement d'état d'un hôte ou d'un service a lieu. Une première utilité de ces gestionnaires d'évènements (particulièrement pour les services) réside dans la capacité de Nagios à résoudre les problèmes de manière préventive avant que quelqu'un ne reçoive une notification. Une seconde utilité est celle d'enregistrer les évènements relatifs aux hôtes ou services dans une base de données externe.

Types de gestionnaires d'évènements

Deux types principaux de gestionnaires d'évènements peuvent être définis : les gestionnaires d'évènements de services et les gestionnaires d'évènements d'hôtes. Les commandes de gestionnaires d'évènements sont définies (de manière optionnelle) dans chaque définition d'hôte et de service. Comme ces gestionnaires d'évènements ne sont associés qu'avec des hôtes ou des services particuliers, je les appellerai "locaux". Si un gestionnaire d'événement local a été défini pour un service ou un hôte, il sera exécuté lorsque cet hôte ou ce service changera d'état.

Vous pouvez aussi spécifier des gestionnaires d'évènements globaux qui doivent fonctionner à chaque changement d'état d'hôte ou de service en utilisant les options global_host_event_handler et global_service_event_handler de votre fichier de configuration principal. Les gestionnaires d'évènements globaux sont exécutés immédiatement, avant même d'exécuter un gestionnaire local d'événement d'hôte ou de service.

Quand les commandes de gestionnaires d'évènements sont-elles exécutées ?

Les commandes de gestionnaires d'évènements de service et d'hôte sont exécutées lorsqu'un service ou un hôte :

A quoi correspondent les états d'erreur "soft" et "hard" dont vous parlez ? Ils sont décrits ici.

Ordre d'exécution des gestionnaires d'évènements

Les gestionnaires globaux d'évènements sont exécutés avant les gestionnaires locaux que vous avez configurés pour des hôtes ou services spécifiques.

Comment écrire des commandes de gestionnaires d'évènements ?

Dans la plupart des cas, les commandes de gestionnaires d'évènements seront des scripts écrits en shell ou en perl. Ils doivent comporter au moins les macros suivantes comme arguments :

Macros de gestionnaire d'événement de service : $SERVICESTATE$, $STATETYPE$, $SERVICEATTEMPT$
Macros de gestionnaire d'événement d'hôte : $HOSTSTATE$, $STATETYPE$, $HOSTATTEMPT$

Les scripts doivent examiner les valeurs des arguments qui leur sont passés et permettre d'exécuter les actions nécessaires en fonction de ces valeurs. Le meilleur moyen de comprendre comment les gestionnaires d'évènements doivent fonctionner est de prendre un exemple. Heureusement pour vous, il y en a un ci-dessous. Il y a aussi des exemples de scripts de gestionnaires d'évènements dans le sous-répertoire eventhandlers/ de la distribution de Nagios. Certains de ces scripts montrent l'usage des commandes externes pour implémenter la supervision redondante des hôtes.

Autorisations d'exécution des commandes de gestionnaires d'évènements

Les commandes de gestionnaires d'évènements que vous configurerez s'exécuteront avec les permissions de l'utilisateur grâce auquel Nagios tourne sur votre machine. Cela présente un problème pour les scripts qui essaient de redémarrer les services du système, car, pour ce genre de tâches, les privilèges de root sont généralement nécessaires.

Vous devrez donc évaluer le type de gestionnaires d'évènements que vous implémentez et donner les permissions juste nécessaires à l'utilisateur nagios pour exécuter les commandes du système. Vous pourrez essayer d'utiliser sudo pour cela. L'implémentation, c'est votre travail. Lisez les docs et décidez ce que vous voulez mettre en place. Je vous laisse régler ces quelques détails...

Débogage des commandes de gestionnaires d'évènements

Lorsque vous déboguez des commandes de gestionnaires d'évènements, je vous conseille fortement d'autoriser la journalisation des réessais de service, réessais d'hôtes, et commandes de gestionnaires d'évènements. Toutes ces options sont configurées dans le fichier de configuration principal. Permettre la journalisation de ces options vous autorisera à voir exactement quand et pourquoi les commandes de gestionnaires d'évènements sont exécutées.

Quand vous aurez achevé le débogage des commandes de gestionnaires d'événement, vous voudrez probablement interdire la journalisation des réessais d'hôtes et de services. Ils peuvent rapidement remplir votre fichier journal, mais si vous avez autorisé la rotation des journaux, vous pouvez négliger cela.

Exemple de gestionnaire d'événement de service

L'exemple ci-dessous suppose que vous supervisez le serveur HTTP de la machine locale et que vous avez spécifié restart-httpd comme commande de gestionnaire d'événement pour la définition du service HTTP. Je supposerai également que vous avez donné à l'option <max_check_attempts> une valeur supérieure ou égale à 4 (i.e le service est contrôlé 4 fois avant qu'on ne considère qu'il a un réel problème). Un exemple de définition ressemblerait à ceci .....

define service{
	host_name			somehost
	service_description		HTTP
	max_check_attempts		4
	event_handler			restart-httpd
	...other service variables...
	}

Maintenant que le service a été défini, nous devons définir le gestionnaire d'événement comme une commande. Remarquez les macros que je passe à la commande du gestionnaire d'évènements, elles sont importantes !

define command{
	command_name	restart-httpd
	command_line	/usr/local/nagios/libexec/eventhandlers/restart-httpd  $SERVICESTATE$ $STATETYPE$ $SERVICEATTEMPT$
	}

Maintenant, nous allons écrire le script de gestionnaire d'événement (c'est le fichier /usr/local/nagios/restart-httpd).

#!/bin/sh
#
# Script de gestionnaire d'événement pour redémarrer le serveur web sur la machine locale
#
# Note: Ce script redémarrera le serveur web si on essaie de le joindre 
#       3 fois (dans un état "soft")ou si le serveur web finit
#       par tomber dans un état d'erreur "hard"
#


# What state is the HTTP service in?
case "$1" in
OK)
	# The service just came back up, so don't do anything...
	;;
WARNING)
	# We don't really care about warning states, since the service is probably still running...
	;;
UNKNOWN)
	# We don't know what might be causing an unknown error, so don't do anything...
	;;
CRITICAL)
	# Aha!  The HTTP service appears to have a problem - perhaps we should restart the server...

	# Is this a "soft" or a "hard" state?
	case "$2" in
		
	# We're in a "soft" state, meaning that nagios is in the middle of retrying the
	# check before it turns into a "hard" state and contacts get notified...
	SOFT)
			
		# What check attempt are we on?  We don't want to restart the web server on the first
		# check, because it may just be a fluke!
		case "$3" in
				
		# Wait until the check has been tried 3 times before restarting the web server.
		# If the check fails on the 4th time (after we restart the web server), the state
		# type will turn to "hard" and contacts will be notified of the problem.
		# Hopefully this will restart the web server successfully, so the 4th check will
		# result in a "soft" recovery.  If that happens no one gets notified because we
		# fixed the problem!
		3)
			echo -n "Restarting HTTP service (3rd soft critical state)..."
			# Call the init script to restart the HTTPD server
			/etc/rc.d/init.d/httpd restart
			;;
			esac
		;;
				
	# The HTTP service somehow managed to turn into a hard error without getting fixed.
	# It should have been restarted by the code above, but for some reason it didn't.
	# Let's give it one last try, shall we?  
	# Note: Contacts have already been notified of a problem with the service at this
	# point (unless you disabled notifications for this service)
	HARD)
		echo -n "Restarting HTTP service..."
		# Call the init script to restart the HTTPD server
		/etc/rc.d/init.d/httpd restart
		;;
	esac
	;;
esac
exit 0

Le script donné à titre d'exemple ci-dessus essaiera de redémarrer le serveur web sur la machine locale à deux occasions différentes : après qu'on ait essayé de redémarrer le service HTTP pour la troisième fois (dans un état d'erreur "soft") et après que le service soit tombé dans un état "hard". L'état "hard" ne devrait pas arriver, car le script devrait redémarrer le service quand il se trouve encore dans un état "soft" (i.e la troisième tentative de contrôle), mais est laissé au cas où.

Il faut noter que le gestionnaire d'événement de service sera seulement exécuté la première fois que le service tombe dans un état "hard". Cela empêche Nagios de poursuivre l'exécution du script pour redémarrer le serveur web quand il est dans un état "hard".