Page History

Introduction

Le gestionnaire d'événements est un système de commandes optionnelles événement ( event handlers ) permet d'exécuter une commande   ( scripts ou exécutables )   qui sont lancées sera lancée dès qu'un hôte ou un check changent d'état.  

L'un des usages classique est la possibilité pour Shinken Enterprise de régler des problèmes en amont.

Voici quelques types d'usage :

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
• relancer un check défaillant,
• créer un ticket dans un outil de support ,;
• tracer Tracer des événements dans une base de données ,
• redémarrer un hôte,
• ;
• Informer informer un Shinken distant ;
• .

Quand les commandes sont-elles exécutées?

Elles sont exécutées :

• lorsque le statut de l'élément est en SOFT et à chaque réception d'une vérification de statut,
• lorsque le statut de l'élément passe en HARD non OK (WARNING, CRITICAL, UNKNOWN),
• lorsque le statut de l'élément passe en OK.

Pour plus de détail sur les états SOFT et HARD voir la page suivant : États "HARD" et "SOFT"

Type d'événements

Il y a différents types de gestionnaire d'événements que vous pouvez définir pour gérer les changements d'état :

• gestionnaire spécifique pour les hôtes
• gestionnaire spécifique pour les checks 

Le gestionnaire d'événements propose des fonctionnalités similaires aux notifications (lancement de certaines commandes) mais les événements sont appelés à chaque changement d'état, SOFT ou HARD.  

Chaque hôte et check peut individuellement avoir un gestionnaire d'événements. Vous pouvez le spécifier dans les définitions de vos Hôtes et checks en utilisant le paramètre "event_handler" 

• ..

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, les Shinken active le mécanisme de gestionnaires d'événement ( event handlers ).

Ce comportement peut être surchargé ( sont activés. Ils peuvent être activés ou désactivés ) globalement en utilisant le paramètre "enable_event_handlers" dans  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

Les gestionnaires d'événements spécifiques pour les hôtes et pour les checks peuvent être activés ou désactivés via le paramètre "event_handler" dans les définitions de vos hôtes et checks.  

Les gestionnaires d'événements spécifiques pour les hôtes et pour les checks ne seront pas exécutés si le paramètre global "enable_event_handlers" est à 0.

Ordre d'exécution

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.

A noter que si le paramètre global est à "désactivé" les gestionnaires d'événements, le paramétrage local n’auront aucun effet

Comme vu précédemment, les gestionnaires d'événements globaux sont exécutés immédiatement avant ceux spécifiques à un hôte ou à un check.  

Ils sont exécutés pour un problème ou rétablissement HARD, immédiatement après l'envoi des notifications.

Ecrire une commande

Les commandes de gestionnaires d’événements sont par exemple des scripts shell ou perl, mais peuvent aussi être tout type d’exécutables qui peuvent être lancés en ligne de commande.  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 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èmessystème, qui nécessitent généralement des accès privilégiés pour faire ce genres 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 le user 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és ?

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 états suivants ( ATTENTION, CRITIQUE, INCONNU ).
• lorsque le statut de l'élément passe en OK

Par exemple : 

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

Les états SOFT et HARD sont décrits en détail dans la page États "HARD" et "SOFT".

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 = Status du check.
• SOFT = État du check.
• 1/2 = Nombre de tentative.
• restart_ntpd = Nom de la commande qui est exécuté