Introduction
Event handlers are optional system commands (scripts or executables) that are run whenever a host or check state change occurs.
An obvious use for event handlers is the ability for Shinken to proactively fix problems before anyone is notified. Some other uses for event handlers include:
- Restarting a failed check
- Entering a trouble ticket into a helpdesk system
- Logging event information to a database
- Cycling power on a host
- etc.
Note that cycling power on a host that is experiencing problems with an automated script should not be implemented lightly. Consider the consequences of this carefully before implementing automatic reboots.
When Are Event Handlers Executed?
...
- Is in a SOFT problem state
- Initially goes into a HARD problem state
- Initially recovers from a SOFT or HARD problem state
SOFT and HARD states are described in detail here.
Event Handler Types
There are different types of optional event handlers that you can define to handle host and state changes:
- Host-specific event handlers
- check-specific event handlers
Event handlers offer functionality similar to notifications (launch some command) but are called each state change, soft or hard. This allows to call handler function and react to problems before Shinken raises a hard state and starts sending out notifications.
Individual hosts and checks can have their own event handler command that should be run to handle state changes. You can specify an event handler that should be run by using the "event_handler" directive in your host and check definitions.
Enabling Event Handlers
Event handlers can be enabled or disabled on a program-wide basis by using the enable_event_handlers in your main configuration file.
Host- and check-specific event handlers can be enabled or disabled by using the "event_handler_enabled" directive in your host and check definitions. Host- and check-specific event handlers will not be executed if the global enable_event_handlers option is disabled.
Event Handler Execution Order
As already mentioned, global host and check event handlers are executed immediately before host- or check-specific event handlers.
Event handlers are executed for HARD problem and recovery states immediately after notifications are sent out.
Writing Event Handler Commands
Le gestionnaire d'événements est un système de commandes optionnelles (scripts ou exécutables) qui sont lancées 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. Quelques types d'usage :
- relancer un check défaillant
- créer un ticket dans un outil de support
- tracer des événements dans une base de données
- Redémarrer un hôte
- etc.
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
Ils peuvent être activés ou désactivés globalement en utilisant le paramètre "enable_event_handlers" dans le fichier de configuration.
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 désactivé.
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
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.
Utilisation des Données en tant que Variable suivantes permettent de régler le comportement de la commande en fonction de l'événement géré :
Pour les Event handler commands will likely be shell or perl scripts, but they can be any type of executable that can run from a command prompt. At a minimum, the scripts should take the following data as arguments:For checks:
- $SERVICESTATE$
- $SERVICESTATETYPE$
- $SERVICEATTEMPT$
For HostsPour les hôtes:
- $HOSTSTATE$
- $HOSTSTATETYPE$
- $HOSTATTEMPT$
The scripts should examine the values of the arguments passed to it and take any necessary action based upon those values.
Permissions For Event Handler Commands
Event handler commands will normally execute with the same permissions as the user under which Shinken is running on your machine. This can present a problem if you want to write an event handler that restarts system checks, as root privileges are generally required to do these sorts of tasks.
Droits pour le gestionnaire d'événements
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.
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 celaIdeally you should evaluate the types of event handlers you will be implementing and grant just enough permissions to the shinken user for executing the necessary system commands. You might want to try using sudo to accomplish this.