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.
Pour chaque élément (hôte, check ou cluster) activé dans la configuration, les données suivantes sont sauvegardées:
| Type de donnée | Commentaire |
|---|---|
| Identifiant unique de l'élément | L'UUID est un champ interne à Shinken permettant d'identifier un élément (hôte, check ou cluster) de manière unique |
| Données d'ordonnancement | Date de la dernière et de la prochaine vérification |
| Statut actuel | Statut actuel de l'élément |
| Dernier changement de statut | Date du dernier changement de statut et statut précédent |
| Contexte | Indique si l'hôte est en Flapping, a une Prise en compte ou des périodes de maintenance. Dans le cas des Périodes de maintenance et des Prises en compte, l'auteur, date et commentaires sont également sauvegardées. |
| Résultat et résultat long | Résultat et résultat long de la dernière vérification |
| Contacts | Ensemble des contacts (identifiés par leur nom) qui ont reçu une notification concernant l'élément |
| Problèmes sources | Lorsque l'élément possède des liens avec d'autres éléments, lorsque cet élément est en erreur, l'identifiant unique des autres éléments affectés sont également sauvegardés. Aussi, si un élément en erreur a affecté l'élément actuel, l'identifiant unique de l'élément source du problème est sauvegardé |
Le module MongodbRetention se charge de sauvegarder la rétention dans une base de données Mongo. L'avantage de ce type de rétention est qu'il peut, contrairement à la rétention par fichiers plats, être utilisé dans un environnement distribué avec plusieurs Schedulers. Plus de détails sont disponibles sur les cas d'utilisations de ce type de rétention dans la page Configurer la rétention des données.
Pour l'utiliser, il faut activer ce module sur le Scheduler pour lequel on veut sauvegarder la rétention.
Cette configuration s'effectue dans le fichier de configuration du Scheduler concerné. Dans Shinken Entreprise, la définition des Schedulers se trouve /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
...
...
...
} |
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.
L'installation de Shinken comporte une installation de Mongo. Il est donc possible d'utiliser un serveur Shinken comme serveur utilisé pour la rétention.
Bien évidemment, un serveur externe peut être utilisé pour sauvegarder la rétention ; dans cette hypothèse il est préférable d'activer l'utilisation d'un tunnel SSH et de configurer le serveur Mongo pour n'écouter que sur une interface réseau locale. Cela permet de garantir la sécurité des données sauvegardées sans avoir à se préoccuper de la complexité de configurer Mongo ; par défaut le tunnel ssh est désactivé pour rester compatible avec les versions antérieures de Shinken.
root@serveur_shinken # su - shinken shinken@serveur_shinken $ ssh-keygen shinken@serveur_shinken $ ssh-copy-id user_distant@serveur_mongo [...] shinken@serveur_shinken $ ssh user_distant@serveur_mongo user_distant@serveur_mongo $ |
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
use_ssh_tunnel 1
ssh_user shinken
ssh_keyfile ~/.ssh/id_rsa
# 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 faire plusieurs définition de module de rétention.
Même si ce n'est pas obligatoire, nous vous conseillons de faire une fichier séparé par définition de module nommé du nom du module de rétention ( dans un but de clarté de votre configuration ) |
Ne pas utiliser "localhost" ou "127.0.0.1" comme URI de la base Mongo lorsqu'il y a plusieurs Schedulers dans le même royaume. Des explications détaillées sur ce problème sont présentes dans la page Configurer la rétention des données. |