Page History

Concept

Le gestionnaire d'événements est un système de commandes optionnelles ( event handler ) permet d'exécuter une commande ( scripts ou exécutables ) qui sont lancées 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 ;...

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

Activer

/Désactiver les gestionnaires d'événements

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

dans Shinken

Il est possible de rajouter le paramètre 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 ) ) .

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

enable_event_handlers=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 Editer un Hôte#Chapitre - Gestionnaire d'événements, Editer un Cluster#Chapitre - Gestionnaire d'événements et Editer un check#Chapitre - Gestionnaire d'événements )

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

Ecrire une commande

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

 Le paramètrelog_event_handlers dans le fichier de configuration /etc/shinken/shinken.cfg  (voir la pageFichier de configuration ( shinken.cfg )) permet d'activer ou de désactiver les logs du déclenchement des commandes.

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

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

Le chapitre Gestionnaire d'événements, dans l'onglet expert de la page d'édition des hôtes, clusters et checks ( voir les pages Editer un Hôte, Editer un Cluster et  Editer un check ), 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 "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 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 ?

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

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

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 

• é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 n'est pas confirmé ( SOFT ) et une dernière fois lors de la confirmation ( HARD ) du statut.
  Ensuite, aucune commande ne sera plus exécutée tant que le statut ne redevient pas OK.
  
• Il n'y a pas d'exécution de commande par le gestionnaire d'événements lorsqu'un élément est dans une période de maintenance ( Image Added ).

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

Dans le fichier /etc/shinken-user/configuration/daemons/arbiters/arbiter_cfg_overload.cfg( voir la page Surcharge des paramètres du démon ( arbiter_cfg_overload.cfg ) ), le paramètre event_handler__hard_state__trigger_on_any_status_change permet d'activer ce comportement ( pour tous les éléments de Shinken ).

                                                       # 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 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 ) ), 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 : 

[YYYY-MM-DD HH:MM:SS] INFO: [ NOM DU SCHEDULER

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

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

 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

Pour le gestionnaire d'évènements d'un check : 

[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