| Scroll Ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Description
Le module named-pipe permet à Shinken de récupérer des informations via un fichier "passe plat" ( un pipe ) que l'on peut remplir de la manière de notre choix.
Par exemple, ce module peut envoyer des informations à des hôtes possédant des checks passifs (checks qui au lieu d'effectuer une vérification régulière, va attendre de recevoir des données, plus d'informations sur les checks passifs ici : Mode actif et mode passif ).
Pour un exemple d'utilisation du module, veuillez vous référer à la section exemple d'utilisation.
Activation du module
Le module named-pipe est un module qui peut être activé sur le démon Receiver et de l'Arbiter.
- L'activation du module s'effectue en ajoutant le nom de ce module dans le fichier de configuration du démon Receiver ( ou de l'Arbiter ).
- Pour ce faire, ouvrer le fichier de configuration du Receiver à l'emplacement /etc/shinken/receivers/, et ajouter le nom de votre module "
named-pipe".
Exemple: par défaut, nous livrons un module dont le nom est "named-pipe":
| Code Block | ||
|---|---|---|
| ||
define receiver {
[...]
modules Module 1, Module 2, named-pipe
[...]
} |
Pour prendre en compte le changement de configuration, redémarrer l'Arbiter:
| Code Block |
|---|
service shinken-arbiter restart |
Configuration
Nous ne livrons pas de configuration par défaut. Vous en trouverez une configuration par défaut ici : named-pipe.cfg
Il faut ensuite placer ce fichier avec les autres modules dans /etc/shinken/modules/
| Note | ||||
|---|---|---|---|---|
Pensez à modifier les droits de lecture du fichier /etc/shinken/modules/named-pipe.cfg et de changer son propriétaire : Donner les droits d'écriture :
Changer de propriétaire :
|
| Code Block | ||
|---|---|---|
| ||
## Module: named-pipe
## Loaded by: Receiver
# Receive passive host and service results, typically from check_mk plugins.
# No other commands or inputs accepted (Restricted to host and service results)
define module {
module_name named-pipe
module_type named_pipe
command_file /var/lib/shinken/shinken.cmd
} |
Détails des sections composant le fichier de configuration
Identification du module
Il est possible de définir plusieurs instances de module de type named-pipe dans votre architecture Shinken.
- Chaque instance devra avoir un nom unique.
| Nom | Type | Unité | Défaut | Commentaire | ||
|---|---|---|---|---|---|---|
| Texte | --- | named-pipe | Nous vous conseillons de choisir un nom en fonction de l'utilisation du module pour que votre configuration soit simple à maintenir. Doit être unique. | ||
| Texte | --- | named-pipe | Ne peut être modifié. |
Configuration du fichier passe-plat
| Nom | Type | Unité | Défaut | Commentaire | ||
|---|---|---|---|---|---|---|
| Chemin | --- | /var/lib/shinken/shinken.cmd | Endroit où le module ira lire les informations à envoyer aux éléments concernés. |
| Anchor | ||||
|---|---|---|---|---|
|
Exemple d'utilisation du module
| Code Block |
|---|
chown shinken:shinken named-pipe.cfg
chmod 644 named-pipe.cfg |
module
au receiverOuvrir le fichier /etc/shinken/receivers/receiver-master.cfg- modules named-pipe
Création d'un check passif
Dans l’interface de configuration, il faut :
- à présent créer le un check passif à associer à un hôte, en passif, non actif, et volatile, car si nous souhaitons recevoir une notification dès un changement d'état. L'expiration de l'état de fraîcheur doit également être paramétrée.
- Appliquer le modèle d'hôte à un hôte accessible sur le réseau ( le paramètre "adresse" doit être rempli avec un nom d'hôte ou IPv4 accessible ).
Voici un exemple
avec la syntaxe via fichiers cfg, modèle de check dédié aude fichier de configuration d'un check passif et d'un 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 1
freshness_threshold 300
register 0
check_interval 1
retry_interval 1
}
define host{
name TRAP-modele
register 0
}
|
| Note | ||
|---|---|---|
| ||
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 5mn, 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 secondes, 300 pour 5mn ). 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éfinit 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" ). 0
} |
Script interpréteur des traps
- Maintenant il faut un script (plugin) qui va se charger d’interpréter les futures traps SNMP reçues pour les envoyer à Shinken (à travers le module named-pipe et le fichier shinken.cmd).
- Ajouter le script suivant que l’on appellera submit_check_result dans le dossier des plugins Shinken (/var/lib/shinken-user/libexec/):
| Code Block |
|---|
#!/bin/bash # 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) echocmd="/bin/echo" CommandFile="/var/lib/shinken/shinken.cmd" # get the current date/time in seconds since UNIX epoch datetime=`date +%s` # create the command line to add to the command file cmdline="[$datetime] PROCESS_SERVICE_CHECK_RESULT;$1;$2;$3;$4" # append the command to the end of the command file $echocmd "$cmdline" >> $CommandFile |
- 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 test-trap TRAP 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 sur l'hôte est accessible via le réseau ).