Le démon Scheduler récupère les informations de statut des checks et des hôtes. Ces statuts sont ensuite utilisés pour déclencher l'envoi des notifications, et pour être affichés dans l'interface de Visualisation.
Quand un démon Scheduler redémarre, il perd l'ensemble des statuts qu'il avait en mémoire. L'ensemble des checks et hôtes affectés à ce Scheduler sont alors en statut "Inconnu", ce qui déclenche potentiellement (selon les paramètres) l'envoi de notifications pour tous les checks, et insère ces statuts "Inconnu" dans les données d'historique et de SLA.
Pour éviter ce problème, un module de rétention doit être accroché sur chaque Scheduler. Ce module a pour rôle de sauvegarder les statuts des éléments dans le Scheduler lorsqu'il s'éteint, et de charger ces statuts lorsqu'il démarre. Les statuts des hôtes et checks ne sont plus perdus au redémarrage du Synchronizer et on évite les problèmes d'envoi des notifications et de pollution des SLA.
Lorsqu'on a un Scheduler en cours de fonctionnement avec un module de rétention, et qu'on veut changer de module de rétention, on ne peut pas simplement changer le module dans la configuration du Scheduler et redémarrer l'Arbiter.
Lors du redémarrage de Shinken pour prendre en compte le changement de configuration, le démon Scheduler redémarre avec le nouveau module de rétention, qui n'a pas les données sauvegardées avant l'extinction. On a pour ce premier redémarrage les mêmes problèmes que si le Scheduler n'a pas de module de rétention.
Pour ne pas perdre les données lors du changement du module de rétention, il faut donc effectuer les opérations suivantes:
On veut changer le type de rétention d'un démon Scheduler. On prendra dans l'exemple le cas d'un démon Scheduler qui a le module PickleRetentionFile. On veut changer cette rétention par une rétention de type Mongo (MongodbRetention).
On commence par ajouter un second module de rétention au Scheduler.
define scheduler {
...
modules PickleRetentionFile, MongodbRetention
...
} |
Dans ce cas, il faut aussi s'assurer que la configuration du module de rétention Mongo est correcte (identifiants à la base notamment). Le fichier de configuration du module de rétention Mongo se trouve à l'emplacement suivant: /etc/shinken/modules/retention-mongodb.cfg.
Pour que le changement de configuration soit pris en compte, on redémarre l'Arbiter.
$ /etc/init.d/shinken-arbiter restart |
La propagation de la configuration peut être longue (quelques secondes a quelques minutes selon la taille de l'infrastructure). Il est donc conseillé d'attendre quelques minutes pour s'assurer que la configuration soit propagée jusqu'au Scheduler avant de continuer la procédure. Les modules chargés dans le Scheduler peuvent être visualisés avec les checks du Pack shinken. |
On veut ensuite déclencher une sauvegarde de la rétention. Avec cette sauvegarde, la rétention sera sauvegardée par les 2 modules de rétention configurés, dans notre cas, dans un fichier ET dans la base Mongo.
Pour déclencher la sauvegarde de la rétention, on éteint le démon Scheduler:
$ /etc/init.d/shinken-scheduler stop |
La rétention est maintenant sauvegardée par les 2 modules. Le premier module de rétention devient redondant. On peut alors conserver seulement le nouveau module de rétention.
On change alors la configuration de notre Scheduler pour ne garder que le second module:
define scheduler {
...
modules MongodbRetention
...
} |
Pour finaliser la prise en compte de la configuration, il faut dans l'ordre, redémarrer le Scheduler précédemment éteint, puis redémarrer l'Arbiter pour propager la nouvelle configuration. Lorsque le Scheduler va recevoir la liste de ses modules, il chargera la rétention depuis le module MongodbRetention:
$ /etc/init.d/shinken-scheduler start $ /etc/init.d/shinken-arbiter restart |
Le changement de module de rétention du Scheduler a bien été effectué. En plus, la double sauvegarde de rétention a permis de ne pas perdre les données de rétention en changeant de module.