| Scroll Ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Voir la mise en place de la configuration du module : Module receiver-module-webservice
Exemple de l'hôte et du check qui vont permettre de vérifier la bonne réception des traps
Création d'un check passif
Dans l’interface de configuration, il faut créer le check à associer à un hôte, en passif, non actif, et volatile, car nous souhaitons recevoir une notification dès un changement d'état. L'expiration de l'état de fraîcheur ( freshness_threshold ) doit également être paramétrée.
Voici un exemple avec la syntaxe d'un fichier de configuration, modèle de check dédié au modèle d'hôte "TRAP-modele" :
| Code Block |
|---|
define service{
service_description TRAP
check_command check-host-alive
host_name TRAP-modele
is_volatile 1
passive_checks_enabled 1
active_checks_enabled 0
check_freshness 1
freshness_threshold 300
register 0
check_interval 1
retry_interval 1
}
define host{
name TRAP-modele
register 0
}
|
Appliquer le modèle d'hôte "TRAP-modele" à un hôte accessible sur le réseau (le paramètre "adresse" doit être rempli), par exemple un hôte "test-trap".
| title | Rappels sur le fonctionnement des checks passifs |
|---|
La configuration de check présentée ci-dessus est celle d'un check passif. Le statut d'un check de ce type va être mis à jour manuellement via la réception de traps SNMP.
Si aucun statut n'est reçu de manière passive pour ce check au bout de 5min, Shinken déclenche une vérification manuelle pour éviter d'avoir un statut trop ancien et non représentatif de l'état de l'élément représenté par le check. Ce comportement est configuré via les options "check_freshness" ( pour l'activation de ce comportement ), "check_command" ( pour la commande de vérification lancée par Shinken ) et "freshness_threshold" ( en seconde, 300 pour 5min ).
Par contre, ce comportement peut entraîner des changements de statuts du check si l'intervalle d'envoi des statuts vers le check ( traps SNMP dans notre exemple ) est supérieur à l'intervalle défini par l'option "freshness_threshold". Il faut donc avoir conscience de ce comportement et régler la valeur de l'option "freshness_threshold" ou bien désactiver cette fonctionnalité pour ce check ( "check_freshness 0" ).
Script interpréteur des traps
Le script va se charger d’interpréter les futurs traps SNMP reçus pour les envoyer à Shinken.
Pour un hôte
Ajouter le script suivant que l’on appellera submit_host_result_to_receiver dans le dossier des plugins Shinken (/var/lib/shinken-user/libexec/ ) :
| Code Block |
|---|
#!/bin/bash
# get the current date/time in seconds since UNIX epoch
datetime=`date +%s`
# Arguments:
# $1 = host_name (Short name of host that the service is associated with)
# $2 = return_code (An integer that determines the state of the service check, 0=OK, 1=WARNING, 2=CRITICAL,3=UNKNOWN).
# $3 = plugin_output (A text string that should be used as the plugin output for the service check)
# Beware to update user/password and shinken-srv address
curl -u user:password -X POST -d "time_stamp=$datetime&host_name=$1&return_code=$2&output=$3" http://shinken-srv:7760/push_check_result |
| Warning | ||
|---|---|---|
| ||
Penser à modifier les valeurs suivantes dans le script :
|
On le rend exécutable et on le donne à l’utilisateur Shinken.
| Code Block |
|---|
chown shinken:shinken /var/lib/shinken-user/libexec/submit_host_result_to_receiver
chmod +x /var/lib/shinken-user/libexec/submit_host_result_to_receiver |
Pour tester le script et simuler une réception d'un trap translaté au format Shinken, il suffit d’exécuter la commande suivante qui va faire passer l'hôte en état critique :
| Code Block |
|---|
/var/lib/shinken-user/libexec/submit_host_result_to_receiver HÔTE 2 "test envoi trap - CRITIQUE" |
| Info |
|---|
Les arguments sont:
|
L'hôte devrait passer en critique, et si au bout de la période du seuil de fraîcheur, aucun nouveau trap n'a été reçu, alors la commande check-host-alive fera repasser le check à OK ( si bien sûr l'hôte est accessible via le réseau ).
| Warning | ||
|---|---|---|
| ||
Si vous ne voyez pas votre hôte passer en critique, il est possible que vous n'ayez pas désactivé la vérification active sur votre hôte. Pour modifier cela, rendez-vous dans l'interface de configuration, cliqué sur votre hôte et dans supervision, mettez à Faux l'actif activé comme sur l'image ci-dessous :
|
Pour un check
Script interpréteur des traps
Ajouter le script suivant que l’on appellera submit_check_result_to_receiver dans le dossier des plugins Shinken ( /var/lib/shinken-user/libexec/ ) :
| Code Block |
|---|
#!/bin/bash # get the current date/time in seconds since UNIX epoch datetime=`date +%s` # Arguments: # $1 = host_name (Short name of host that the service is associated with) # $2 = svc_description (Description of the service) # $3 = return_code (An integer that determines the state of the service check, 0=OK, 1=WARNING, 2=CRITICAL,3=UNKNOWN). # $4 = plugin_output (A text string that should be used as the plugin output for the service check) # Beware to update user/password and shinken-srv address curl -u user:password -X POST -d "time_stamp=$datetime&host_name=$1&service_description=$2&return_code=$3&output=$4" http://shinken-srv:7760/push_check_result |
| Warning | ||
|---|---|---|
| ||
Penser à modifier les valeurs suivantes dans le script :
|
On le rend exécutable et on le donne à l’utilisateur Shinken.
| Code Block |
|---|
chown shinken:shinken /var/lib/shinken-user/libexec/submit_check_result_to_receiver chmod +x /var/lib/shinken-user/libexec/submit_check_result_to_receiver |
Pour tester le script et simuler une réception d'un trap translaté au format Shinken, il suffit d’exécuter la commande suivante qui va faire passer le service en état critique :
| Code Block |
|---|
/var/lib/shinken-user/libexec/submit_check_result_to_receiver test-trapHÔTE TRAPCHECK 2 "test envoi trap - CRITIQUE" |
| Info |
|---|
Les arguments sont:
|
Le check devrait passer en critique, et si au bout de la période du seuil de fraîcheur, aucun nouveau trap n'a été reçu, alors la commande check-host-alive fera repasser le check à OK ( si bien sûr l'hôte est accessible via le réseau ).
| Warning | ||
|---|---|---|
| ||
Si vous ne voyez pas votre check passer en critique, il est possible que vous n'ayez pas désactivé la vérification active sur votre check. Pour modifier cela, rendez-vous dans l'interface de configuration, cliqué sur votre check et dans supervision, mettez à Faux l'actif activé comme sur l'image ci-dessous :
|
