Concept de la rétention
Dans Shinken Entreprise, lorsque des éléments sont en supervision, des vérifications régulières sont effectuées sur les hôtes, clusters et checks.
Suite à ces vérifications, un statut (OK, Attention, Critique, Inconnu) ainsi que un ou plusieurs contextes (Flapping, Période de maintenance, Prise en compte) sont attribués à chaque élément.
Sans rétention, lorsque Shinken doit être redémarré (maintenance du serveur de supervision, ou bien mise à jour de Shinken), ces statuts et contextes sont perdus, et les éventuelles notifications déclenchées sur un état non voulu seront envoyées !
Activer la rétention permet de conserver les états des hôtes, clusters et checks entre les redémarrages de Shinken et ainsi bénéficier d'une vision claire de l'état des éléments supervisés à tout moment.
Cette rétention s'effectue au niveau du démon Scheduler qui est chargé d'ordonnancer la vérification des éléments et de récupérer et analyser les résultats de ces vérifications.
Les différents types de rétention
Plusieurs modules de rétention sont livrés dans une installation de Shinken Entreprise afin d'être utilisés dans le Scheduler.
La rétention par fichier plat
Il s'agit du type de rétention le plus simple. C'est la rétention par fichier plat (module PickleRetentionFile) qui est d'ailleurs utilisée par défaut dans les Schedulers.
Avec ce type de module, les statuts et contextes des éléments sont sauvegardés dans un fichier plat, sur le même serveur que le Scheduler sur lequel il est activé.
La rétention par une base de données
Ce type de rétention est utilisé par le module MongodbRetention, qui stocke les statuts et contextes des éléments supervisés dans une base de données Mongo.
Ce module a l'avantage de pouvoir être utilisé avec des architectures de Shinken distribuées sur plusieurs serveurs, avec plusieurs schedulers.
Cadre d'utilisation des différents types de modules de rétention
Utilisation de la rétention par fichiers plats
Par défaut dans Shinken Entreprise, les Schedulers utilisent le module PickleRetentionFile, qui sauvegarde les données de rétention dans un fichier plat.
Ce module, simple et rapide, possède cependant ses limites dans un environnement distribué.
Le cas de figure montrant les limites de la rétention par fichiers plats est le suivant:
- On dispose dans notre architecture Shinken d'un royaume possédant plusieurs Schedulers.
- A chaque démarrage de l'Arbiter, celui ci répartit les hôtes du royaume de manière équitable entre les Schedulers de ce royaume. Chaque Scheduler sauvegarde donc les données de rétention dans le fichier qu'il a à disposition.
- Au prochain démarrage de l'Arbiter, celui ci va redistribuer à nouveaux les hôtes du royaume dans les Scheduler. Mais, rien ne garantit que la répartition soit identique à la précédente.
- Un hôte qui était auparavant sur le Scheduler 1, avec ses données de rétention sauvegardées dans le fichier du serveur 1, est maintenant sur le Scheduler 2. Le Scheduler 2 ne possède pas les données de retention de cet hôte, on a alors une perte de données
|
Lorsque chaque royaume possède un unique Scheduler, le cas de figure précédent ne se produit pas.
Chaque hôte, affecté à un royaume, sera distribué sur l'unique Scheduler du royaume, qui aura toutes les données de rétention nécessaires.
On ne retrouve pas le cas provoquant la perte de données ci-dessus.
|
Utilisation de la retention Mongo
Pour pallier au cas d'erreur lié à l'utilisation d'une rétention par fichier plat dans un royaume avec plusieurs Schedulers, la rétention avec Mongo peut être utilisée.
Cependant, la configuration doit être vérifiée pour éviter de tomber dans des cas d'erreurs classique.
Par exemple, on est dans un environnement possédant un royaume avec plusieurs Schedulers, sur des serveurs différents.
- Sachant que la rétention par fichier plat ne pourra pas fonctionner, on active sur nos Schedulers la rétention Mongo. Mais par defaut, la configuration du module de retention Mongo précise localhost comme adresse de la base à utiliser.
- On se retrouve alors avec la rétention enregistrée sur 2 bases distinctes, et on est dans le même cas d'erreur qu'avec la rétention par fichiers.
|
Aussi, de la même manière que dans le cas de la rétention par fichier plats, ce problème disparait lorsqu'on possède des royaumes avec un seul Scheduler.
Chaque Scheduler possède tous les éléments du royaume, et a donc toutes les données de rétention nécessaires.
|
La solution pour utiliser la rétention Mongo dans un royaume avec plusieurs Schedulers est de spécifier une adresse d'un serveur Mongo (autre que localhost) dans la configuration de la rétention Mongo.
Dans ce cas la, tous les Schedulers du royaume sauvegarderont les données de rétention dans une base de données centrale. En cas de besoin, toutes les données de retention seront disponible au même endroit et la restauration des statuts et contextes pourra être effectuée sans problèmes.
|
Comment configurer la rétention
Changer le module de rétention d'un Scheduler
Le choix du module de rétention s'effectue directement dans le fichier de configuration du Scheduler en questions. Dans Shinken Entreprise, les Schedulers sont définis dans /etc/shinken/schedulers.
define scheduler {
...
...
...
#======== Modules to enable for this daemon =========
# Available:
# - PickleRetentionFile : (if you have only one scheduler into a realm) save retention data (element state and scheduling) into a file
# - MongodbRetention : (if you have more than one scheduler into a realm) save retention data (element state and scheduling) into a mongodb database
modules MongodbRetention
...
...
...
} |
Configurer la rétention Mongo
Une fois la rétention Mongo activée sur les Schedulers concernés, il faut modifier l'URI de la base Mongo pour pointer vers l'adresse de la base de données qui hébergera les données de rétention.
define module {
#======== Module identity =========
# Module name. Must be unique
module_name MongodbRetention
# Module type (to load module code). Do not edit.
module_type mongodb_retention
#======== Mongodb connection =========
# uri: to connect the mongodb server
uri mongodb://ip_du_serveur/?safe=false
# database: which mongodb database to use
database shinken
••••
# Advanced option if you are running a cluster mongodb environnement
# replica_set
} |
Il se peut également que plusieurs royaumes veulent définir une rétention Mongo sur un serveur différent pour chaque royaume. Dans ce cas, il faut dupliquer la définition du module.
Le module_type sera identique, tandis que le reste de la configuration du module pourra changer. Il faudra ensuite, dans la configuration du Scheduler, spécifier le nom du module approprié.
Résumé
|
|