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
|
