Introduction
Les gestionnaires d'évènements sont des commandes optionnelles qui sont exécutées à chaque fois qu'un changement d'état d'un hôte ou d'un service a lieu. Une première utilité de ces gestionnaires d'évènements (particulièrement pour les services) réside dans la capacité de Nagios à résoudre les problèmes de manière préventive avant que quelqu'un ne reçoive une notification. Une seconde utilité est celle d'enregistrer les évènements relatifs aux hôtes ou services dans une base de données externe.
Types de gestionnaires d'évènements
Deux types principaux de gestionnaires d'évènements peuvent être définis : les gestionnaires d'évènements de services et les gestionnaires d'évènements d'hôtes. Les commandes de gestionnaires d'évènements sont définies (de manière optionnelle) dans chaque définition d'hôte et de service. Comme ces gestionnaires d'évènements ne sont associés qu'avec des hôtes ou des services particuliers, je les appellerai "locaux". Si un gestionnaire d'événement local a été défini pour un service ou un hôte, il sera exécuté lorsque cet hôte ou ce service changera d'état.
Vous pouvez aussi spécifier des gestionnaires d'évènements globaux qui doivent fonctionner à chaque changement d'état d'hôte ou de service en utilisant les options global_host_event_handler et global_service_event_handler de votre fichier de configuration principal. Les gestionnaires d'évènements globaux sont exécutés immédiatement, avant même d'exécuter un gestionnaire local d'événement d'hôte ou de service.
Quand les commandes de gestionnaires d'évènements sont-elles exécutées ?
Les commandes de gestionnaires d'évènements de service et d'hôte sont exécutées lorsqu'un service ou un hôte :
A quoi correspondent les états d'erreur "soft" et "hard" dont vous parlez ? Ils sont décrits ici .
Ordre d'exécution des gestionnaires d'évènements
Les gestionnaires globaux d'évènements sont exécutés avant les gestionnaires locaux que vous avez configurés pour des hôtes ou services spécifiques.
Comment écrire des commandes de gestionnaires d'évènements
Dans la plupart des cas, les commandes de gestionnaires d'évènements seront des scripts écrits en shell ou en perl. Ils doivent accepter au moins les macros suivantes comme arguments:
Macros de gestionnaire d'événement de service : $SERVICESTATE$, $SERVICESTATETYPE$, $SERVICEATTEMPT$
Macros de gestionnaire d'événement d'hôte : $HOSTSTATE$, $HOSTSTATETYPE$, $HOSTATTEMPT$
Les scripts doivent examiner les valeurs des arguments qui leur sont passés et exécuter les actions nécessaires en fonction de ces valeurs. Le meilleur moyen de comprendre comment les gestionnaires d'évènements doivent fonctionner est de voir un exemple. Heureusement pour vous, il y en a un ci-dessous. Il y a aussi des exemples de scripts de gestionnaires d'évènements dans le sous-répertoire eventhandlers/ de la distribution de Nagios. Certains de ces scripts montrent l'usage des commandes externes pour implémenter la supervision redondante des hôtes.
Autorisations d'exécution des commandes de gestionnaires d'évènements
Les commandes de gestionnaires d'évènements que vous configurerez s'exécuteront avec les permissions de l'utilisateur grâce auquel Nagios tourne sur votre machine. Cela présente un problème pour les scripts qui essaient de redémarrer les services du système, car, pour ce genre de tâches, les privilèges de root sont généralement nécessaires.
Ideally you should evaluate the types of event handlers you will be implementing and grant just enough permissions to the Nagios user for executing the necessary system commands. You might want to try using sudo to accomplish this. Implementation of this is your job, so read the docs and decide if its what you need. Vous devrez donc évaluer le type de gestionnaires d'évènements que vous implémentez et donner juste les permissions requises à l'utilisateur nagios pour exécuter les commandes du système nécessaires. Vous pourrez essayer d'utiliser sudo pour cela. L'implémentation, c'est votre travail. Donc lisez les docs et décidez si ça correspond à vos besoins.
Débogage des commandes de gestionnaires d'évènements
Lorsque vous déboguez des commandes de gestionnaires d'évènements, je vous conseille fortement d'autoriser la journalisation des réessais de service, réessais d'hôtes, et commandes de gestionnaires d'évènements. Toutes ces options sont configurées dans le fichier de configuration principal. Permettre la journalisation de ces options vous autorisera à voir exactement quand et pourquoi les commandes de gestionnaires d'évènements sont exécutées.
Quand vous aurez achevé le débogage des commandes de gestionnaires d'événement, vous voudrez probablement désactiver la journalisation des réessais d'hôtes et de services. Ils peuvent rapidement remplir votre fichier journal, mais si vous avez autorisé la rotation des journaux, vous pouvez négliger cela.
Exemple de gestionnaire d'événement de service
L'exemple ci-dessous suppose que vous supervisez le serveur HTTP de la machine locale et que vous avez spécifié restart-httpd comme commande de gestionnaire d'événement pour la définition du service HTTP. Je supposerai également que vous avez donné à l'option <max_check_attempts> une valeur supérieure ou égale à 4 (i.e le service est contrôlé 4 fois avant qu'on ne considère qu'il a un réel problème). Un exemple de définition (avec uniquement les champs concernés) ressemblerait à ceci ...
define service{
host_name somehost
service_description HTTP
max_check_attempts 4
event_handler restart-httpd
...other service variables...
}
Une fois que le service a été défini avec un gestionnaire d'évènement, nous devons définir le gestionnaire d'événement comme une commande. Remarquez les macros de la ligne de commande que je passe au gestionnaire d'évènements, elles sont importantes !
define command{
command_name restart-httpd
command_line /usr/local/nagios/libexec/eventhandlers/restart-httpd $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$
}
Maintenant, nous allons écrire le script de gestionnaire d'événement (c'est le fichier /usr/local/nagios/restart-httpd).
#!/bin/sh # # Event handler script for restarting the web server on the local machine # # Note: This script will only restart the web server if the service is # retried 3 times (in a "soft" state) or if the web service somehow # manages to fall into a "hard" error state. # # What state is the HTTP service in? case "$1" in OK) # The service just came back up, so don't do anything... ;; WARNING) # We don't really care about warning states, since the service is probably still running... ;; UNKNOWN) # We don't know what might be causing an unknown error, so don't do anything... ;; CRITICAL) # Aha! The HTTP service appears to have a problem - perhaps we should restart the server... # Is this a "soft" or a "hard" state? case "$2" in # We're in a "soft" state, meaning that Nagios is in the middle of retrying the # check before it turns into a "hard" state and contacts get notified... SOFT) # What check attempt are we on? We don't want to restart the web server on the first # check, because it may just be a fluke! case "$3" in # Wait until the check has been tried 3 times before restarting the web server. # If the check fails on the 4th time (after we restart the web server), the state # type will turn to "hard" and contacts will be notified of the problem. # Hopefully this will restart the web server successfully, so the 4th check will # result in a "soft" recovery. If that happens no one gets notified because we # fixed the problem! 3) echo -n "Restarting HTTP service (3rd soft critical state)..." # Call the init script to restart the HTTPD server /etc/rc.d/init.d/httpd restart ;; esac ;; # The HTTP service somehow managed to turn into a hard error without getting fixed. # It should have been restarted by the code above, but for some reason it didn't. # Let's give it one last try, shall we? # Note: Contacts have already been notified of a problem with the service at this # point (unless you disabled notifications for this service) HARD) echo -n "Restarting HTTP service..." # Call the init script to restart the HTTPD server /etc/rc.d/init.d/httpd restart ;; esac ;; esac exit 0 |
Le script donné à titre d'exemple ci-dessus essaiera de redémarrer le serveur web sur la machine locale à deux occasions différentes : après que le le service HTTP soit essayé pour la troisième fois (dans un état d'erreur "soft") et après que le service soit tombé dans un état "hard". L'état "hard" ne devrait pas arriver, car le script devrait redémarrer le service quand il se trouve encore dans un état "soft" (i.e la troisième tentative de contrôle), mais est laissé au cas où.
Il faut noter que le gestionnaire d'événement de service sera seulement exécuté la première fois que le service tombe dans un état "hard". Cela empêche Nagios de poursuivre l'exécution du script pour redémarrer le serveur web quand il est dans un état "hard".