Introduction
Une utilisation fréquemment rencontrée lors de la mise en place d'une architecture Shinken distribuée contenant plusieurs royaumes est la gestion de plusieurs services/clients.
Supposons qu'on se trouve dans le scénario suivant:
- La plateforme de supervision est mise en place par une équipe dédiée à la supervision
- L'équipe de supervision dispose d'une interface de Visualisation permettant de visualiser l'ensemble des hôtes présents dans la configuration
- Les hôtes supervisés correspondent à des machines/service dédiées à certains clients
- L'équipe de supervision veut pouvoir mettre à disposition une interface de Visualisation à chaque client qui lui permet de visualiser ses hôtes (mais pas ceux des autres clients)
Une solution dans ce cas de figure est de créer un royaume dans lequel est positionné un Broker.
Architecture mise en place
Explication sur l'archi mise en place (avantages et raisons de cette config la, étapes de configuration)
| Panel |
|---|
SCHEMA ARCHI AVEC SUBREALM SCHEDULER+POLLER+BROKER |
Dans cette page de documentation, on a pour objectif de mettre en place l'architecture suivante:
- L'architecture comporte d'abord un royaume principal (All) qui supervise un certain nombre d'éléments
- Un sous royaume "Client 1" s'occupe de superviser les éléments concernant le client 1.
- L'interface de Visualisation sur le royaume permet de visualiser l'ensemble des hôtes, y compris ceux du royaume "Client 1".
- L'interface de Visualisation du royaume "Client 1" sera mise à disposition au client et ne permet de visualiser que les éléments supervisés par le royaume "Client 1"
| Panel |
|---|
|
Configuration des démons
La première étape pour la mise en place de cette architecture est la mise en place des démons.
On suppose dans notre exemple que les démons du royaume All sont hébergés sur une machine "server_1" et les démons du royaume "Client 1" sont hébergés sur une machine "server_2".
La configuration se fera alors en majeure partie sur "server_1", puisque c'est la on est situé le démon Arbiter qui gère la configuration des démons.
Création des royaumes
Sur "server_1", on commence alors par créer le royaume "Client 1". Pour cela, on crée le fichier /etc/shinken/realms/client1.cfg qui aura le contenu suivant:
| Code Block |
|---|
define realm {
# Realm name. Must be unique
realm_name Client 1
# default: 0 = this realm is not the default one
# 1 = this realm is the default, so an element or a daemon is missing a
# realm property, then this one will be used
default 0
# List of sub-realms for this realm
#realm_members
} |
Le royaume "Client 1" est un sous-royaume du royaume All. Il faut pour qu'il soit considéré comme un sous royaume modifier la configuration du royaume All pour le spécifier, comme dans l'exemple suivant :
| Code Block | ||
|---|---|---|
| ||
define realm {
# Realm name. Must be unique
realm_name All
# default: 0 = this realm is not the default one
# 1 = this realm is the default, so an element or a daemon is missing a
# realm property, then this one will be used
default 1
# List of sub-realms for this realm
realm_members Client 1
} |
Création des démons du royaume "Client 1"
Une fois le royaume "Client 1" créé, il faut ensuite créer les démons qui font partie de ce royaume.
Cette création des démons se fait en 3 temps.
On commence d'abord par créer les fichiers .ini des démons sur "server_2"
Code Block title Sur server_2 shinken-daemons-create --ini --type=scheduler --port=7768 --name=scheduler-client-1 shinken-daemons-create --ini --type=poller --port=7771 --name=poller-client-1 shinken-daemons-create --ini --type=broker --port=7772--name=broker-client-1
On créé ensuite les fichiers de configuration sur l'Arbiter ("server_1")
Code Block title Sur server_2 shinken-daemons-create --cfg --type=scheduler --port=7768 --name=scheduler-client-1 --address=<adresse_server_2> shinken-daemons-create --cfg --type=poller--port=7771 --name=poller-client-1 --address=<adresse_server_2> shinken-daemons-create --cfg --type=broker--port=7772 --name=broker-client-1 --address=<adresse_server_2>
On modifie la propriété "realms" des fichiers de configuration de ces démons pour les mettre dans le royaume "Client 1" (/etc/shinken/schedulers/scheduler-client-1.cfg, /etc/shinken/brokers/broker-client-1.cfg, /etc/shinken/pollers/poller-client-1.cfg).
Par exemple, pour le Scheduler:Code Block title /etc/shinken/schedulers/scheduler-client-1.cfg define scheduler { #======== Daemon name and address ========= # Daemon name. Must be unique scheduler_name scheduler-client-1 # IP/fqdn of this daemon (note: you MUST change it by the real ip/fqdn of this server) address <adresse_server_2> ... Contenu coupé ... #======== Realm and architecture settings ========= # Realm to set this daemon into realm Client 1 # In NATted environments, you declare each satellite ip[:port] as seen by # *this* scheduler (if port not set, the port declared by satellite itself # is used) #satellitemap poller-1=1.2.3.4:1772, reactionner-1=1.2.3.5:1773 #======== Enable or not this daemon ========= # 1 = is enabled, 0 = is disabled enabled 1 }
Gestion des hôtes
Gestion des métriques
Duplication du module Graphite-Perfdata et WebUI pour faire pointer chaque Broker vers le bon Graphite
Gestion des SLA
On laisse par défaut (localhost) ca marche. En plus on peut pas pour le moment configurer la sauvegarde de SLA par royaume donc ca règle le problème