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 de statut.   é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 à 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

Activation des logs

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

 Le Vous pouvez activer les logs en utilisant 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

Paramétrage du mécanisme

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 Par défaut, lorsque le statut d'un élément est confirmé ( 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 ).

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 le comportement de la commande en fonction de l'é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

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

#==================================================================================
#======== 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                                                       # 0 : Disabled (Default)
                                                        #   1 : EnableEnabled
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 Gestionnaire d'événements activé ( clé d'import : 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

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

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 :

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 : Des lignes de logs seront alors présentes dans le fichier de log du Scheduler lors du déclenchement de la commande, si les log ont été activées ( voir le chapitre "Activation des logs" plus haut )

[2021YYYY-03MM-17DD 11HH:55MM:14SS] INFO: [ NOM :DU [SCHEDULER scheduler-master ] SERVICE EVENT HANDLER: HOST;Process ntpd;CRITICAL;SOFT;1;manage_ntpd
...
[2021-03-17 11:56:13] INFO   : [ scheduler-master ] SERVICE 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: HOST;Process ntpd;OK;SOFT;2;manage_ntpd

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