Contexte
Il peut arriver qu'un réseau sécurisé soit complètement isolé du réseau central et que vous ayez besoin de distribuer les alertes des équipements et services supervisés de ce réseau isolé, vers le réseau central.
Nous vous conseillons alors de mettre en place une architecture Shinken sur ce réseau isolé (qui sera également accessible depuis l'intérieur de ce réseau par les administrateurs) et de le faire dialoguer avec le réseau Shinken Central. De cette manière, il sera possible de n'autoriser qu'un seul flux réseau (entre 2 IP spécifiques), dans le sens réseau isolé vers réseau central.
Prenons par exemple la surveillance de l'hôte H1 et de son check C1 dans l'infrastructure Shinken du réseau isolé.
L'objectif est d'obtenir sur l'architecture centrale Shinken la réplique de H1 et C1 (avec des objets qui ont exactement les mêmes noms, et qui sont en mode passif), et que leurs états en central soient un mirroir des états réels déterminés depuis les Pollers/Scheduler du réseau isolé.
Le dialogue pourra se faire via deux mécanismes possibles :
- les commandes Event Handlers (gestionnaire d'évènements) qui, si paramétrés sur l'hôte ou le check, enverra une commande définie sur cet hôte ou ce check.
- les commandes OCSP/OCHP (Obsessive Compulsive Service Processor / Obsessive Compulsive Host Processor) qui permet de doubler toutes les commandes de checks ou d'hôtes, par une autre commande, globale, définie dans le fichier de configuration central.
Ces commandes seront alors récupérés par le module ws-arbiter du daemon Receiver en central, et permettra le changement de l'état de l'hôte ou du check concerné.
Mécanismes
Le choix du mécanisme est important dans votre architecture.
Les Event Handlers sont paramétrables par check et par hôtes, via l'UI de configuration, alors que les commandes OCSP et OCHP sont paramétrables de manière globale dans Shinken, via le fichier /etc/shinken/shinken.cfg
Si vous décidez d'envoyer absolument tous les résultats vers le Shinken central, de la même manière, via une même commande, alors les commandes OCSP et OCHP seront plus rapidement mises en place, et vous n'aurez pas à vous soucier d'un paramétrage par hôtes ou checks.
Par contre, si vous souhaitez n'envoyer que certains résultats vers le central, il sera plus judicieux de passer par les Event Handlers.
Les Event Handlers
Les Event Handlers sont expliqués dans la documentation ici.
| Le paramétrage des Events Handler est possible via fichier CFG mais peut être également entièrement paramétré via l'UI de configuration. |
OCSP (checks) /OCHP (hôtes)
Les options sont à définir dans /etc/shinken/shinken.cfg :
obsess_over_services=1
obsess_over_hosts=1
Ces valeurs déterminent si Shinken va, à chaque exécution de la commande de supervision de l'hôte ou du service, exécuter une autre commande.
Cette commande est également à définir de manière globale dans le fichier shinken.cfg.
Pour la commande "obsession" des checks : ocsp_command=ma-commande-OCSP-checks
Pour la commande "obsession" des hôtes : ochp_command=ma-commande-OCHP-hotes
Cette commande est exécutée après les commandes "Event Handler" et les commandes de notification. La valeur des propriétés est le nom court d'une commande qui est définie dans vos objets Shinken.
Architecture
|
Installation - Les étapes de mise en place
Pour cet exemple, basé sur le schéma ci dessus, le check C1 sur l'hôte H1 du réseau isolé doit envoyer l'information en central, sur un même nom de check de l'hôte du même nom H1 (mirroir).
Mise en place de l'archi Shinken sur le réseau isolé
- Installation Shinken complète (tous les démons)
- Mise en supervision de l'hôte H1 avec un check attaché appelé C1
- sur C1 : event_handler_enabled 1 et commande définie via la propriété event_handler
Paramétrage sur le réseau Central
- création de H1 et C1 (attention, les noms doivent être identiques)
- sur C1 : Mode Passif : active_checks_enabled 0 et passive_checks_enabled 1
- C1 doit appeler une commande qui génère un retour unknown "retour inconnu" (dans le cas ou il ne recoit pas d'information externe)
- Fraicheur : check_freshness 1 et freshness_threshold 300-> si au bout de 300s je n'ai pas recu d'information via les outils externes -> retour statut "retour inconnu"