View Source

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

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"

Shinken Entreprise V02.05.00 > Une interface de Visualisation dédiée à un sous-royaume > Untitled Diagram (12).png

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:

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 :

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"

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")

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:

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 métriques

La configuration des métriques récupérées dans chaque royaume peut se faire de 2 manières différentes:

Toutes les métriques remontées par les hôtes et les checks (tous royaumes confondus) sont sauvegardées et lues sur "server_1":
- Simplicité de configuration et de maintenance: Tous les royaumes lisent sur le même serveur, ce qui permet d'avoir un seul module Graphite-perfdata utilisé par tous les Brokers
- Performances: Tous les Brokers font leur requêtes de métriques sur une seule machine centrale. Cette machine peut devenir surchargée lorsqu'on a beaucoup d'hôtes/checks et/ou de sous-royaumes différents
Les métriques sont sauvegardées et lues de manière indépendante par chaque royaume:
- Montée en charge: Puisque chaque royaume gère ses propres métriques, l'ajout de nouveaux sous-royaume n'influe pas sur les performances de autres royaumes
- Configuration un peu plus complexe: Pour profiter de cette architecture, chaque royaume doit être configuré pour gérer ses propres métriques

Dans cette documentation, on détaille la mise en place d'une configuration permettant à chaque royaume de gérer ses propres métriques. Cette procédure de configuration a pour l'avantage d'être utilisable dans un nombre plus élevé de cas de figure.

La configuration mise en place dans la suite de cette procédure est celle représentée sur le schéma ci-contre.

La configuration d'un Broker au niveau des métriques s'organise de la façon suivante:

Lecture des métriques: Le Broker a un module WebUI, qui en plus des paramètres de l'interface de Visualisation, définit quel serveur Graphite est utilisé pour la lecture des métriques.
Ecriture des métriques: Le module Graphite-Perfdata du Broker permet de définir ou seront écrites les métriques des éléments reçus par ce Broker.

Dans le schéma ci-contre, chaque Broker a un module WebUI et un module Graphite différent pour permettre de dissocier la configuration des 2 Brokers au niveau des métriques.

Shinken Entreprise V02.05.00 > Une interface de Visualisation dédiée à un sous-royaume > Untitled Diagram-Page-2 (3).png

Création des modules WebUI-client1 et Graphite-Perfdata-client1

Pour mettre en place la configuration décrite dans le schéma précédent, on commence par créer les modules WebUI-client1 et Graphite-Perfdata-client1. La manière la plus simple de créer ces modules est de dupliquer les modules existants WebUI et Graphite-Perfdata.

Cette duplication s'effectue en copiant les fichiers de configuration et en renommant les modules:

Module WebUI-client1

Copie du module

cp /etc/shinken/modules/webui.cfg /etc/shinken/modules/webui-client1.cfg

Renommage du module

define module {
    #======== Module identity =========
    # Module name. Must be unique
    module_name               WebUI-client1

    # Module type (to load module code). Do not edit.
    module_type               webui


[... Suite du fichier ...]


}

Module Graphite-Perfdata-client1

Copie du module

cp /etc/shinken/modules/graphite.cfg /etc/shinken/modules/graphite-client1.cfg

Renommage du module

define module {

    #======== Module identity =========
    # Module name. Must be unique
    module_name                 Graphite-Perfdata-client1

    # Module type (to load module code). Do not edit.
    module_type                 graphite_perfdata



[... Suite du fichier ...]


}

Une fois les modules créés, on les attache sur le Broker:

define broker {

    #======== Daemon name and address =========
    # Daemon name. Must be unique
    broker_name               broker-client1

    # IP/fqdn of this daemon (note: you MUST change it by the real ip/fqdn of this server)
    address                   client1

    [... Contenu caché ...]


    #======== Modules to enable for this daemon =========
    # Available:
    # - Simple-log            : save all logs into a common file
    # - WebUI                 : visualisation interface
    # - Graphite-Perfdata     : save all metrics into a graphite database
    # - sla                   : save sla into a database
    # - Livestatus            : TCP API to query element state, used by nagios external tools like NagVis or Thruk
    modules                   Simple-log, WebUI-client1, Graphite-Perfdata-client1, sla, Livestatus


	[... Suite du fichier ...]
}

Configuration du royaume All

Configuration du royaume Client 1

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