Announcement

Collapse
No announcement yet.

Event handler

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • cheupi
    replied
    Redémarrer un service Windows

    Bonjour,

    Je suis nouveau ici.
    J'ai installé Nagios 2.10 + Centreon 1.4.1 et mon but en ce moment est de redémarrer automatiquement un service windows lorsqu'il s'arrête.

    J'ai configurer un service Centreon (nommé "check_service_win") qui utilise check_snmp_win.pl pour remonter si mon service windows (dans mon cas "HTTP SSL" pour ma phase de test) est démarré ou non et le tout via SNMP.

    Mon service Centreon me remonte : "No services matching "HTTP SSL" found : CRITICAL" si le service est éteind et "
    1 services active (matching "HTTP SSL") : OK" si le service est démarré..

    Jusque là tout va bien.

    Mais maintenant je souhaite redémarrer ce service windows en auto quand le service Centreon me dit "No services matching "HTTP SSL" found : CRITICAL".

    Quelqu'un peut m'aider ?

    Merci d'avance.

    Leave a comment:


  • sergestage
    replied
    Je viens de voir le sujet un peu a labourre :roll:
    Je crois que pour ton pb il y a les services volatils enfin c'est ce que j'ai compris dans la doc de nagios.
    Moi je l'utilse pour mes event handler je crois que ca marche pas trop mal j'ai jamais eu le temps de vraiment regarder si il y avais aucun pb

    Leave a comment:


  • crabinho
    replied
    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:

    Leave a comment:


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

    Leave a comment:


  • crabinho
    replied
    oui normalement c'est ca.

    Leave a comment:


  • wistof
    replied
    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.

    Leave a comment:


  • DonKiShoot
    replied
    +1

    Leave a comment:


  • crabinho
    replied
    Tout depend comment tu ecris le event handler. C'est toi qui choisit quand est ce qu'il est pris en compte, exemple :
    Code:
    #!/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

    Leave a comment:


  • wistof
    replied
    Originally posted by 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...
    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.

    Leave a comment:


  • wistof
    replied
    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 ?

    Leave a comment:


  • templuche
    replied
    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.

    Leave a comment:


  • wistof
    replied
    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

    Leave a comment:


  • xspoon
    replied
    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...

    Leave a comment:


  • surcouf
    replied
    Re: Event handler

    Originally posted by 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 ?
    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.

    Leave a comment:


  • rom
    replied
    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)

    Leave a comment:

Working...
X