| Scroll Ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Contexte
Cette documentation a pour but de montrer comment un cluster peu peut superviser des hôtes et/ou des checks venant de royaumes différents. Exemple : Vous souhaitez superviser un site internet depuis 2 datacenter différents qui sont dans des royaumes différents et remonter l'information dans un cluster pour n'être alerté qu'en cas de défaillance des 2 datacenters.
Le concept est d'utiliser le module receiver-module-webservice pour envoyer des traps
Le flux réseau ne sera donc ouvert que dans le sens Déporté vers Central.
Les installations dans des zones sécurisées n'auront donc pas de connexion entrante.La solution proposée permettra de remonter n’importe quel résultat de checks ou d'hôtes vers l'installation centralele cluster.
- Il s'agit cependant d'un contournement et une utilisation généralisée sur tous les éléments supervisés sera fastidieux.Nous vous conseillons de faire des clusters et de remonter seulement les informations des clusters pour avoir une vue agrégée en centralfastidieuse.
Prenons par exemple la surveillance de l'hôte H1 dans l'infrastructure Shinken du réseau isolé:
L'objectif estd
'obtenir sur l'
architecture centrale Shinken la réplique de H1 (avec un objet qui a exactement le même nom, et qui est en mode passif), et que son état en central soit un miroir des états réels déterminés depuis les Pollers/Scheduler du réseau isolé.un site internet www.shinken-enterprise.com dans 2 royaumes différent et le résultat sera envoyé sur un hôte hôte_global dont les checks seront appelés via un cluster nommé cluster_global :
- Le dialogue se fera via le mécanisme du Gestionnaire d'événements qui, si paramétré sur l'hôte ou le check, enverra une commande définie sur cet hôte le cluster ou ce le check du cluster.
- Ces commandes seront alors récupérées par le module receiver-module-webservice du daemon démon Receiver en central, et permettront le changement de l'état de l'hôte ou du check cluster concerné.
- Il faudra définir de chaque coté un élément avec le même nom (hôtes ou couple hôte/check) sur le royaume principal, l'hôte avec les checks portant le même nom ainsi qu'un cluster pour que la remontée d'information ait bien lieu.
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é du site doit envoyer l'information en centralà l'hôte sur le royaume principal, sur le même nom de d'hôte H1 (miroir)check.
Mise en place de l'architecture Shinken sur le réseau isolé
- Installez Shinken Entreprise
- Mettez en place la supervision des éléments sur les différents royaumes
- Mettez en place la surveillance de l'hôte H1 hote_global 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 |
|---|
/var/lib/shinken-user/libexec/submit_host_result_to_receiver "$HOSTADDRESS$" $SERVICESTATEID$ "$SERVICEOUTPUT$" IP-RECEIVER-CENTRAL |
Si on doit effectuer l'envoi du statut d'un check, voici l'exemple de la commande ayant le nom "envoi-statut-check" et avec la ligne de commande :
| Code Block |
|---|
/var/lib/shinken-user/libexec/submit_check_result_to_receiver "$HOSTADDRESS$" "$SERVICEDISPLAYNAME$" $SERVICESTATEID$ "$SERVICEOUTPUT$" IP-RECEIVER-CENTRAL |
Le contenu du script se trouve dans cette partie de la documentation : Script d'interprétation des traps avec le module receiver-module-webservice
| Panel |
|---|
- Sur hote_globalsur H1: depuis l'interface de configuration, dans l'onglet Expert, activez le le Gestionnaire d'événement (ou via un cfg passez la propriété event_handler_enabled à 1)
- et Et sélectionnez la commande "envoi-statut-hote" pour la Commande lancée par le gestionnaire d’événement (ou via cfg, définie avec la propriété event_handler)
Paramétrage sur le réseau Central
Configuration :
- Paramétrez votre Module receiver-module-webservice
- pensez 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 la propriété "Shinken accepte les états reçus depuis des outils externes pour cet hôte" à VRAI
- ou via un fichier de définition CFG ( utilisation d'une source d'import ) :
- active_checks_enabled 0
- passive_checks_enabled 1
| Panel |
|---|
Pour
génèrergénérer un retour CRITIQUE dans le cas
ouoù 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
recuesreçues
Pour un check, vous pouvez renvoyer un état UNKNOWN avec comme arguments : 3!Pas de données récentes
reçues
Pour que cette commande soit exécutée, dans l'onglet expert de H1, passez la propriété "Vérification que l'état
reçureçut 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 freshnesset freshness_threshold 300 )
| Panel |
|---|
Et voilavoilà, à 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 receiver-module-webservice, vous pouvez exécuter simplement cette commande depuis un terminal :
| Code Block |
|---|
curl -u user:password -X POST -d "time_stamp=`date +%s`&host_name=mon_hote&service_description=mon_check&return_code=0&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 démon Reactionner (port 7769) qui enverra les commandes d'Event Handler, et l'IP hébergeant le daemon démon Receiver (port 77737760 du module receiver-module-webservice) à l'écoute des commandes.







