Contexte
Architecture
| Panel | ||
|---|---|---|
| ||
|
Installation - Les étapes de mise en place
Pour cet exemple, basé sur le schéma ci dessus, la supervision de l'hôte H1 du réseau isolé doit envoyer l'information en central, sur le même nom de d'hôte H1 (miroir).
Mise en place de l'architecture Shinken sur le réseau isolé
- Installez Shinken Entrprise
- Mettez en place la surveillance de l'hôte H1 avec une commande de supervision, par exemple la commande check-host-alive
- Créez la commande qui enverra l'information au Receiver du réseau Shinken central, depuis l'interface de configuration - page des commandes :
Dans notre exemple, pour un objet hôte, créons par exemple la commande ( dans l'interface de configuration ) ayant le nom "envoi-statut-hote" et avec la ligne de commande :
| Code Block |
|---|
curl -d "host_name=$HOSTNAME$&return_code=$SERVICESTATEID$" --data-urlencode "output=Statut de l hote recupere" http://IP-RECEIVER-CENTRAL:7760/push_check_result |
Si on doit effectuer l'envoi du statut d'un check, créons par voici l'exemple de la commande ayant le nom "envoi-statut-check" et avec la ligne de commande :
| Code Block |
|---|
curl -d "host_name=$HOSTNAME$&service_description=$SERVICEDESC$&return_code=$SERVICESTATEID$" --data-urlencode "output=Statut du check recupere" http://IP-RECEIVER-CENTRAL:7760/push_check_result |
Paramétrage sur le réseau Central
- Paramétrez votre module ws-arbiter et pensez bien à l'appeler depuis la définition de votre Receiver dans la propriété module. Redémarrez Shinken pour la prise en compte du module.
- Créez l'hôte H1 (attention, le nom doit être exactement le même que celui défini dans l'architecture Shinken du réseau isolé)
- Passez H1 en mode Passif : depuis l'interface de configuration, onglet Supervision, via la propriété "Les commandes de vérifications sont ordonnancées et lancées par Shinken" à mettre à FAUX et "Shinken accepte les états reçus depuis des outils externes pour cet hôte" à VRAI (ou via CFG : active_checks_enabled 0 et passive_checks_enabled 1)
- Pour génèrer un retour CRITIQUE dans le cas ou l'hôte ne reçoit pas d'information externe, nous vous conseillons de définir la commande de supervision de H1 par la commande "Check Dummy" avec par exemple en argument : 2!Pas de données récentes recues
Pour un check, vous pouvez renvoyer un état UNKNOWN avec comme arguments : 3!Pas de données récentes recues - Pour que cette commande soit exécutée, dans l'onglet expert de H1, passez la propriété "Vérification que l'état reçu des outils externes ne soit pas expiré" à VRAI et passez la propriété "Seuil d'expiration des états reçus des outils externes ( x secondes )" à 300 (ou via CFG : check_freshness 1 et freshness_threshold 300 )
Et voila, à chaque changement d'états de l'hôte H1 du réseau isolé, la commande "envoi-statut-hote" sera lancée, et mettra à jour l'hôte de même nom sur le réseau central.
Troubleshoot
Commande manuelle
Pour tester le bon fonctionnement du module ws-arbiter, vous pouvez exécuter simplement cette commande depuis un terminal :
| Code Block |
|---|
curl -d "host_name=mon_hote&return_code=0" --data-urlencode "output=Statut OK" http://IP-DU-RECEIVER:7760/push_check_result |
Vérifiez alors que l'état de votre hôte depuis l'interface de visualisation de votre réseau Shinken Central a bien été modifié.
Réseau
Au minimum, pour faire communiquer les deux infrastructures, il faut autoriser une communication entre l'IP hébergeant le daemon Reactionner (port 7769) qui enverra les commandes d'Event Handler, et l'IP hébergeant le daemon Receiver (port 7773) à l'écoute des commandes.