Event handler

[wistof]

Hello tout le monde,

J'ai un probléme avec la gestion des event_handlers par Nagios. Les event_handler sont lancés lors d'un changment d'état. Lorsque mon service passe en HARD, il lance mon event_handler, mais le service reste en HARD (la commande n'a pas résolu le probléme) donc l'event_handler n'est plus joué par la suite car l'etat ne change pas...

quelqu'un aurait une idée pour contourner le problème ?

[templuche]

quelqu'un aurait une idée pour contourner le problème ?

Intégré le event-handler dans la commande? Exemple:
- le plugin teste si le service Windows tourne
- il ne tourne pas le plugin essaye de le démarrer
- le plugin teste pour vérifier si le service a démarré correctement
- le service a démarré correctement, le plugin remonte "warning, le service a du être redémarré par Nagios"
- le service n'a pas démarré correctment, le plugin remonte "critical, le service n'a pas pu être redémarré"

[rom]

Cette solution est bien si tu veux systematiquement lancer une commande en reponse a un probleme, mais dans le cas present quel difference vu que la commande et son resultat vont surement etre les memes que ceux lancées par le event handler (et etre tous aussi inefficace) ?
(Sachant aussi que le event handler va etre lance dans la phase SOFT NON OK)

[surcouf]

Re: Event handler

Hello tout le monde,

J'ai un probléme avec la gestion des event_handlers par Nagios. Les event_handler sont lancés lors d'un changment d'état. Lorsque mon service passe en HARD, il lance mon event_handler, mais le service reste en HARD (la commande n'a pas résolu le probléme) donc l'event_handler n'est plus joué par la suite car l'etat ne change pas...

quelqu'un aurait une idée pour contourner le problème ?

Si on en savait davantage sur le but à atteindre ou simplement le contexte, on saurait sans doute mieux t'aider.
Les event_handler sont des directives qui définissent une commande (et non pas un plugin dont le nom pourrait porter à confusion) qui peut gérer les différents états (states) SOFT/HARD et les retours d'exécution (status) OK/UNKNOWN/WARNING/CRITICAL afin d'agir en conséquence.
Et c'est bien là tout son champ d'application. J'ai déjà eu l'occasion d'en user pour activer/désactiver les notifications et check actifs d'un Nagios distribué si le serveur maître venait à ne plus donner signe de vie. Mais ces event_handler ne forment qu'une pièce de l'ensemble.

[xspoon]

Lorsque mon service passe en HARD, il lance mon event_handler

à tester mais d'apres les docs, l'event handler se lance à chaque résultat SOFT et au premier résultat HARD.

le nombre d'executions de l'event handler est donc controlé par le max_check_attempts > ce qui finalement te laisse le choix du nombre de relances du handler...

[wistof]

on est bien d'accord, un event_handler n'est pas un plugin.

Mon script event_handler est codé en vbs et gére les différents states et status. Il est basé sur l'event_handler de la doc nagios.

Il lancé sur une machine windows via NRPE. Donc ma commande event_handler dans la conf du service fait appel a check_nrpe.

Tout cela fonctionne correctement.

Mon probléme, c'est lorsque la commande exécute dans le script vbs ne permet pas de faire repartir mon process qui est monitoré, et bien l'event_handler n'est relancé car il n'y a pas de changement d'état

[templuche]

mais dans le cas present quel difference vu que la commande et son resultat vont surement etre les memes que ceux lancées par le event handler (et etre tous aussi inefficace) ?

La différence c'est que la commande lance elle même la correction donc elle effectue la tentative de correction à chaque fois.

[wistof]

j'ai aussi un peu de mal à saisir.

C'est le plugin check_ (la commande) qui ferait aussi office de event_handler mais sans etre appeler par le event_handler.

Il faudrait donc que mon check interpréte les states et les status ?

[wistof]

Lorsque mon service passe en HARD, il lance mon event_handler

à tester mais d'apres les docs, l'event handler se lance à chaque résultat SOFT et au premier résultat HARD.

le nombre d'executions de l'event handler est donc controlé par le max_check_attempts > ce qui finalement te laisse le choix du nombre de relances du handler...

oui, ça pourrait etre une possibilité de jouer max_check_attemps et de faire réagir le script vbs (event_handler) sur les SOFT. Le but étant de ne passer en HARD.

[crabinho]

Tout depend comment tu ecris le event handler. C'est toi qui choisit quand est ce qu'il est pris en compte, exemple :

#!/bin/sh
#
# Event handler script for restarting the web server on the local machine
#
# Note: This script will only restart the web server if the service is
#       retried 3 times (in a "soft" state) or if the web service somehow
#       manages to fall into a "hard" error state.
#


# 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

[DonKiShoot]

+1

[wistof]

Ok.

Donc si je mets Max_check_attempts à 10, et que dans mon script event_handler, je gére le SOFT entre 3 et 10. Ca devrait etre bien.
Sauf que j'aurais ma notification que lorsque je passerais en HARD.

[crabinho]

oui normalement c'est ca.

[wistof]

je pourrais descendre le Max_check_attempts (par exemple 5) et augmenter les Normal_check_interval et Retry_check_interval

[crabinho]

Rectification :

Je me suis plante juste au dessus ops: ,

Ok.

Donc si je mets Max_check_attempts à 10, et que dans mon script event_handler, je gére le SOFT entre 3 et 10. Ca devrait etre bien.
Sauf que j'aurais ma notification que lorsque je passerais en HARD.

si tu met Max_check_attempts à 10 et que tu lance le Event handler a 5 par exemple, Il y a 3 possibilites :
1) le event handler regle le probleme avant que le 10ieme check ai eu lieu -> le probleme est regle et pas de notification, si l'admin ne regarde pas le log, il ne saura jamais qu'il y a eu un probleme.

2) le event handler regle le probleme apres que le 10ieme check ai eu lieu (pas assez de temps entre les checks) -> le probleme est regle et une notification a ete envoyee (normal puisque le service est devenu HARD entre Temps) mais au final tout est corrige sans que l'admin est besoin d'intervenir.

3) le event handler ne regle pas le probleme -> tant pis, le nombre de check du service continue a augmente jusqu'a 10 et l'admin est prevenu.


Voila j'espere que j'ai ete clair. Sinon hesite pas a demander. A toi de gerer les intervalles entre les checks pour etre sur que le event handler fini avant la notification : c'est dommage d'etre reveille a 1h00 du mat. si c'est pour voir que le probleme vient d'etre regle!


----Edit----

Desole pour l'erreur au dessus mais je tape plus vite que je pense, et pourtant je ne tape pas vite... :wink: