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

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

• relancer un check défaillant

objectif est de pouvoir invoquer une commande pour réagir à 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 d'utilisations :

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

Quand les événement sont-ils exécutés?

Ils sont exécutés quand un hôte ou un check :

• est dans un état de problème SOFT

• arrive directement dans un état de problème HARD 

• revient d'un état de problème SOFT ou HARD 

Les états SOFT et HARD sont décrits en détail ici.

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" 

Activer le 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 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 or not the event handlers
                                    # default: 1 (enabled)
                                    # 0 (disabled)
enable_event_handlers=1

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

 Le paramètrelog_event_handlers Par défaut, les event handlers sont activés. Ils peuvent être 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 pageFichier de configuration ( shinken.Si ce cfg )) permet d'activer ou de désactiver les logs du déclenchement des commandes.

enable_event_handlers=0

Ordre d'exécution

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

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 ( Remplacement dynamique de contenu - Anciennement les Macros ) ) pour contrôler

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.  

Droits pour le gestionnaire d'événements

• .

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 ] SERVICE EVENT HANDLER: 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 

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èmes, qui nécessitent généralement des accès privilégiés pour faire ce genres de tâches.