Page History

Concept

Le gestionnaire d'événement événements ( event handlershandler ) permet d'exécuter une commande ( scripts ou exécutables ) qui sera lancée dès qu... ) lorsqu'un hôte ou un check changent d'état.   élément ( cluster, hôte, check ) change de statut, puis à chaque vérification jusqu'à ce que le statut soit confirmé ( HARD ). 

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

Le mode de fonctionnement :

• Le Scheduler vérifie si la commande doit être exécutée ou non
• C'est ensuite le Reactionner qui exécutera la commande.
  • Dans une architecture distribuée, il est donc essentiel de s'assurer que les scripts ou exécutables à lancer se trouvent sur la machine du Reactionner ( il est crucial de s'assurer que les droits d'accès sont correctement configurés pour la machine du Reactionner ).
  • L'utilisation d'un tag de Reactionner permet de contrôler quel Reactionner exécutera la commande

Exemples 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

Mettre en place les gestionnaires d'évènements dans Shinken

Activer/Désactiver les gestionnaires d'événements dans Shinken

Il est possible de rajouter le paramètre

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 voir la page Fichier de configuration ( shinken.cfg ) )

pour activer ou de désactiver les gestionnaires d'événements de tous les éléments dans Shinken.

                                    # Enable or not the event handlers
                                    # default: 1 (enabled)
                                    # 0 (disabled)
enable_event_handlers=0

Fonctionnement du mécanisme

Activer/Désactiver les logs des gestionnaires d'évènements dans Shinken

 Le paramètrelog_event_handlers

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 ).

Ce comportement peut être surchargé ( activés ou désactivés ) globalement 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/shinken.cfg  (Voir Surcharge des paramètres du démon ( arbiter_cfg_overloadvoir la page Fichier de configuration ( shinken.cfg )) permet d'activer ou de désactiver les logs du déclenchement des commandes.

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

Comment utiliser le gestionnaire d'événements d'un élément ( Hôtes, Cluster, Checks )

Le chapitre Gestionnaire d'événements,

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

Écrire une commande

, permet de configurer le gestionnaire d'événements d'un élément.

Il est possible : 

• Activer ou désactiver le gestionnaire d'événements de l'élément
• Spécifier la commande à exécuter et ses paramètres.
• Préciser le tag de Reactionner afin de contrôler quels Reactionners exécuteront la commande.

Ajouter une commande au gestionnaire d'événements d'un élément

La commande sera exécutée par un Reactionner :

• Les commandes exécutées par le gestionnaire d’événements correspondent aux objets commandes de Shinken ( voir la page Les commandes ).
• Comme pour les notifications, les scripts exécutés auront besoin d'information ( paramètre ), notamment pour les connexions à un outil de ticket, ou par exemple pour se connecter à la machine pour supprimer des logs.
• Il est possible d'utiliser des variables ( voir la page Les Variables

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 ?

• événement géré.

Logique d'exécution d'une commande par le gestionnaire d'évènements

Par défaut ( Seulement quand il passe d'un état non OK à OK, ou inversement )

L'exécution de la commande se fera dans les cas suivants :

• Lors d'un changement de statut OK vers statut non-OK ( CRITIQUE , ATTENTION , INCONNU )
  ex : Image Added→ Image Added
• Lors d'un changement statut non-OK ( CRITIQUE , ATTENTION , INCONNU ) versOK. 
  ex : Image Added→ Image Added
  
• À la réception de chaque vérification de statut non-OK ( CRITIQUE , ATTENTION , INCONNU ), tant que le statut

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

Exécution lors de n'importe quel changement de statut non-OK confirmé

En plus des cas précédemment évoqués, la commande peut être exécutée pour chaque changement de statut non-OK confirmé ( HARD ).
ex : Image Added→ Image Added

                                                       # Activate this option to allow Event Handler to execute command on any hard state status change, in addition to its normal behavior.
                                                       # 0 : Disabled (Default)
                                                       # 1 : Enabled

event_handler__hard_state__trigger_on_any_status_change=1

Exécution pendant une période de maintenance

Il est possible d'effectuer l'exécution de la commande lors d'une période de maintenance ( Image Added).

Dans

Log sur le déclenchement des commandes 

, le paramètre no_event_handlers_during_downtimes permet d'activer ce comportement ( pour tous les éléments de Shinken ).

                                                       # By default don't launch even handlers during downtime.
                                                       # Note: the default Nagios behaviour is to allow them. If you want to keep this
                                                       # Nagios behavior, then set this parameter to 0
no_event_handlers_during_downtimes=0

Individuellement pour un check 

Pour un check volatil, la commande sera exécutée par le gestionnaire d'événements pour chaque retour de statut non-OK ( voir la page Checks volatiles ).

• Les notifications seront aussi envoyées pour chaque retour de statut non-OK.

Log d'exécution des commandes

Les logs présents dans le fichier de log du Scheduler ( /var/log/shinken/Scheduler ) lors du déclenchement de la commande par le gestionnaire d'événements : 

Pour le gestionnaire d'évènements d'un hôte : 

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

log_event_handlers=1

[2021YYYY-03MM-17DD 11HH:55MM:14SS] INFO: [ NOM : [ scheduler-masterDU SCHEDULER ] 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

 NOM DE L'HÔTE; NOM DU SERVICE; STATUT DU SERVICE; CONFIRMATION DU STATUT; NOMBRE DE TENTATIVES DE CONFIRMATION DE STATUT; NOM DE LA COMMANDE

[YYYY-MM-DD HH:MM:SS] INFO: [ NOM DU SCHEDULER ] HOST EVENT HANDLER: NOM DE L'HÔTE; STATUT DE L'HÔTE; CONFIRMATION DU STATUT; NOMBRE DE TENTATIVES DE CONFIRMATION DE STATUT; NOM DE LA COMMANDE