Page History

Introduction

Le gestionnaire d'événement ( event handlers ) permet d'exécuter une commande( scripts ou exécutables ) qui sera lancée dès qu'un hôte ou un check changent d'état.   

Comme pour les notifications, l'objectif est de pouvoir invoquer une de vos commandes que vous aurez définie pour réagir suite au changement d'état.

Voici des exemples d'utilisations :

• Redémarrer un hôte.
• Relancer un service sur un hôte.
• Créer un ticket dans un outil de support.
• Tracer des événements dans une base de données.
• Informer un Shinken distant.
• ...

C'est le démon Scheduler qui choisir quand la commande va être lancée et le démon Reactionner va exécuter la commande.

Mise en place

Activer le mécanisme de gestionnaire d'événements

Par défaut, Shinken active le mécanisme de gestionnaires d'événement ( event handlers ).

Ce comportement peut être surchargé ( activés ou désactivés ) globalement en utilisant le paramètre "enable_event_handlers" dans le fichier de configuration /etc/shinken/shinken.cfg. ( Voir la page Fichier de configuration ( shinken.cfg ) )

• Si ce paramètre n'est pas présent dans le fichier, il faudra l'ajouter.
• Par exemple, pour désactiver globalement l'exécution des gestionnaires d'événement.
  
  

enable_event_handlers=0

Paramétrage du mécanisme

Lorsque l'élement est en état "SOFT":

• La commande du gestionnaire d'événement sera lancé a la réception de chaque vérification d'état ( quelque soit le statut ).

Lorsqu'un élément est en état "HARD" :

Par défaut, lorsqu'un élément est en état "HARD", la commande du gestionnaire d'événement ne sera pas lancée même si le statut change pour un des statuts suivants ( ATTENTION, CRITIQUE, INCONNU ).

• Regarder le chapitre "Quand est-ce que vos commandes sont exécutées ?" ci-dessous pour plus de détail sur le fonctionnement.
• Ce comportement peut être surchargé ( activés ou désactivés ) globalement pour activer systématiquement la commande du gestionnaire d'événement
  • en utilisant le paramètre "event_handler__hard_state__trigger_on_any_status_change" dans le fichier de configuration /etc/shinken-user/configuration/daemons/arbiters/arbiter_cfg_overload.cfg ( Voir la page Surcharge des paramètres du démon ( arbiter_cfg_overload.cfg ) ).
  Si ce paramètre a pour valeur "0" ( Désactivé ), la commande du gestionnaire d'événement
• sera lancée si le statut ( OK ) change vers l'un des statuts ( ATTENTION, CRITIQUE, INCONNU )
• sera lancée si le statut ( ATTENTION, CRITIQUE, INCONNU ) change vers le statut ( OK )
NE sera pas LANCER si  le statut ( ATTENTION, CRITIQUE, INCONNU )  change vers l'un des statuts ( ATTENTION, CRITIQUE, INCONNU ).
Si ce paramètre a pour valeur "1" ( Activé ), la commande du gestionnaire d'événement sera lancée pour N'IMPORTE QUEL CHANGEMENT de statut .

#**********************************************************************************
#  This file is the overload of the /etc/shinken/shinken.cfg file
#  IMPORTANT: You MUST edit this file instead of the /etc/shinken/shinken.cfg
#             as the /etc/shinken file can be overwritten by an update
#
#  To set a value, just uncomment it and it will take precedence over the
#  /etc/shinken/shinken.cfg one
#**********************************************************************************



#==================================================================================
#======== Monitoring and scheduling =========

                                                        #  Activate this option to allow Event Handler to execute command on any status change, in addition to its normal behavior.
                                                        #   0 : Disable (Default)
                                                        #   1 : Enable
event_handler__hard_state__trigger_on_any_status_change=0

Associer un gestionnaire d'événement à un élément 

On peut aussi gérer l'activation/désactivation au cas par cas sur les hôtes, les clusters ou les checks.

• Voir le champ event_handler dans l'onglet expert de la page d'édition de vos hôtes, clusters et checks. ( Voir les pages Editer un Hôte, Editer un Cluster et Editer un check ).
  • Vous allez associer une commande en tant que gestionnaire d'événement.
  • Cela pourra être une commande déjà existante ou une que vous aurez faite spécifiquement.

À noter que si le paramètre global est à "désactivé", le paramétrage local n’aura aucun effet.

Écrire une commande

Les commandes de gestionnaires d’événements sont des objets commande de Shinken que vous pouvez définir via la page d'édition des commandes. ( Voir la page Les commandes )

Les exemples de notation de variables suivants permettent de régler le comportement de la commande en fonction de l'événement géré : 

Pour les checks:

• $SERVICESTATE$
• $SERVICESTATETYPE$
• $SERVICEATTEMPT$

Pour les hôtes:

• $HOSTSTATE$
• $HOSTSTATETYPE$
• $HOSTATTEMPT$

Droits pour la commande

Par défaut, la commande est exécutée avec les mêmes droits que ceux de l'utilisateur sous lequel Shinken est démarré sur la machine. Cela peut présenter un problème si vous voulez utiliser un gestionnaire d'événements qui doit redémarrer des services système, qui nécessitent généralement des accès privilégiés pour faire ce genre de tâches.

Dans l'idéal, vous devez évaluer les types de gestionnaires d'événements que vous serez en train de mettre en place et rajouter juste assez de permissions sur l'utilisateur Shinken afin qu'il puisse exécuter les commandes systèmes nécessaires. Vous devrez peut-être utiliser "sudo" pour accomplir cela.

Fonctionnement

Quand est-ce que vos commandes sont exécutées ?

La commande lancée par le gestionnaire d'événements sera exécutée :

• si le statut de l'élément n'est pas confirmé ( SOFT ), à chaque réception de statut. 
• lorsque le statut de l'élément devient confirmé ( HARD ), quel que soit son statut.
  • en suite, dans l'état confirmé ( HARD ), la commande ne sera plus lancée même si le statut change pour un des statuts suivants ( ATTENTION, CRITIQUE, INCONNU ).
• lorsque le statut de l'élément passe en OK

Par exemple : 

Lorsque le paramètre "event_handler__hard_state__trigger_on_any_status_change" a pour valeur "0" ( Désactivé ) :

• La commande sera exécutée si le statut de l'élément passe de ATTENTION - HARD en OK.
• Mais, la commande ne sera pas exécutée si le statut de l'élément passe de ATTENTION - HARD en CRITIQUE - HARD.

Lorsque le paramètre "event_handler__hard_state__trigger_on_any_status_change" a pour valeur "1" ( Activé ) :

• La commande sera exécutée si le statut de l'élément passe de ATTENTION - HARD en OK.
• Et, la commande sera exécutée si le statut de l'élément passe de ATTENTION - HARD en CRITIQUE - HARD.

1 )  Lorsque l'élément est en état non confirmé ( SOFT ):

• • La commande du gestionnaire d'événement sera lancée à la réception de chaque vérification d'état ( quelque soit le statut ).

2 )  Lorsque le statut de l'élément devient confirmé ( HARD ), quel que soit son statut, 

Log sur le déclenchement des commandes 

Vous pouvez activer les logs en utilisant le paramètre log_event_handlers ( par défaut, le paramètre activé )

log_event_handlers=1

Des lignes de logs seront alors présentes dans le fichier de log du Scheduler lors du déclenchement de la commande.

[2021-03-17 11:55:14] INFO   : [ scheduler-master ] SERVICE EVENT HANDLER: HOST;Process ntpd;CRITICAL;SOFT;1;manage_ntpd
...
[2021-03-17 11:56:13] INFO   : [ scheduler-master ] SERVICE EVENT HANDLER: HOST;Process ntpd;OK;SOFT;2;manage_ntpd

• HOST = Nom de l'hôte
• Process ntpd = Nom du check dont la commande de gestion d'événement va être lancé.
• CRITICAL/OK = Statut du check.
• SOFT = État du checkStatut confirmé ( SOFT ) / Statut non confirmé ( HARD ).
• 1/2 = Nombre de tentatives.
• restart_ntpd = Nom de la commande qui est exécuté