Page History

Description

Concept

Shinken ne fournit pas de commandes natives La méthode pour sauvegarder ou restaurer une rétention. Cette page décrit le protocole à suivre pour effectuer ces opérations manuellement.

La procédure de sauvegarde et de restauration dépend du et restaurer manuellement la rétention dépend du type de module de rétention utilisé par vos Schedulers Scheduler :

• PickleRetentionFile
• MongodbRetention

Vous trouverez plus d'information sur ces modules en suivant ces liens :

• Le module PickleRetentionFile ( voir la page Module PickleRetentionFile ( Rétention par fichier plat ) ).
• Le module MongodbRetention ( voir la page Module MongodbRetention ( Rétention en base de

• données centralisée par royaume )

•  ).

Sauvegarde et restauration de la rétention avec le module PickleRetentionFile

Où trouver la rétention Pickle

Lorsque le module PickleRetentionFile est utilisé, la sauvegarde de la rétention se fait rétention est sauvegardée dans un fichier situé au chemin , situé par défaut dans le répertoire suivant : /var/lib/shinken/

Le nom de ces fichiers respecte ce format :

.

REALM_NAME

SCHEDULER_NAME

SCHEDULER_ID

Ce chemin peut toutefois varier selon la configuration spécifique des modules PickleRetentionFile utilisés par les Scheduler ( voir la page Module PickleRetentionFile ( Rétention par fichier plat ) ).

Voici un exemple complet de nom de fichier de rétention Pickle : 

/var/lib/shinken/

Exemple de nom de fichier : 

retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention

Comment sauvegarder la rétention Pickle

Pour sauvegarder ces les fichiers de rétention, il suffit de les copier à l'endroit souhaité avec la commande cp <source> <destination> vers l'emplacement choisi en veillant à préserver leur intégrité et leurs permissions :

cp -a /var/lib/shinken/retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention /root/retention_save/

Cette commande va copier le fichier de rétention retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention dans le dossier nommé /root/retention_save/

• -a : permet de préserver les droits et métadonnées du fichier

Comment restaurer la rétention Pickle

Restauration des fichiers de rétention

Pour restaurer un fichier de rétention Pickle, il suffit de le remettre à l'endroit depuis lequel ils ont été copiés : faut le copier dans le dossier /var/lib/shinken/ Si les fichiers ont été copiés dans un dossier nommé /root/retention_save/, alors la commande pour restaurer la rétention devrait ressembler à ça :

cp -a /root/retention_save/retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention /var/lib/shinken/ 

Avant de restaurer les fichiers Pickle, assurez-vous qu'il n'y a pas de fichier du même nom dans /var/lib/shinken/, ou assurez-vous de les sauvegarder si besoin.

Redémarrage du Scheduler

Après avoir restauré les fichiers de rétention, il faut redémarrer le Scheduler pour que les changements fassent effet soient pris en compte :

service shinken-scheduler restart

Sauvegarde et restauration de la rétention avec le module MongodbRetention

Où

trouver la rétention

Mongo

Avec Lorsque le module MongodbRetention est utilisé, la rétention se trouve est sauvegardée dans la base base shinken ( par défaut ) dans les collections de MongoDB ( voir la page Module MongodbRetention ( Rétention en base de données centralisée par royaume ) ), au sein des collections retention_hosts_raw et retention_services_raw. 

Comment sauvegarder la rétention

Mongo

Avant de lancer la sauvegarde

Avant de procéder à la sauvegarde de sauvegarder la rétention, il est conseillé ( si possible ) de redémarrer le Scheduler afin de forcer la mise à jour de la rétention , et donc d'avoir et d’obtenir ainsi des données plus fraiches fraîches : 

service shinken-scheduler restart

Sauvegarder la

rétention

Pour enregistrer les données de ces collections, on utilise la commande mongodump la rétention, il faut lancer les deux commandes suivantes :

mongodump -d DATABASE_NAMEshinken -c COLLECTIONretention_hosts_NAMEraw -h HOST_NAME --poty=HTTP_PORT --ssl -o OUTPUT_NAME

Explication des paramètres :

-d DATABASE_NAME

-c COLLECTION_NAME

-h HOST_NAME

--port=HTTP_PORT

Port HTTP de la base MongoDB  ( et non du serveur ). Par défaut le port utilisé est 27017.

Ce port peut être trouvé par défaut dans le fichier /etc/mongod.conf ( ou /etc/mongos.conf si vous utilisez MongoDB en cluster ).

Si vous avez changé le port de MongoDB ( par défaut 27017 ) il faut le préciser via ce paramètre, même en local.

--ssl

-o OUTPUT_NAME

Ces deux commandes vont créer deux dossiers à l'emplacement /root/retention_mongo/ ( assurez vous que ce chemin existe ) nommés retention_hosts_11_10_2021 et retention_services_11_10_2021 contenant des fichiers .json et .bson qui contiennent les données des collections correspondantes.

Quelques exemples de mongodump

Sauvegarde de la rétention sur une MongoDB en local

o /root/retention_mongo/ ( + MONGO_DB_CONNECTION_OPTIONS )

mongodump -d shinken -c retention_services_raw -o /root/retention_mongo/ ( +  MONGO_DB_CONNECTION_OPTIONS )

• shinken : nom de la base définie dans la configuration du module (voir la page Module MongodbRetention ( Rétention en base de données centralisée par royaume ) ).
• /root/retention_mongo/ : dossier où seront sauvegardées les rétentions. Le chemin peut être absolu ou relatif ( dans ce dernier cas, le dossier sera créé à l’emplacement où la commande est exécutée ).
• retention_hosts_raw / retention_services_raw : noms des collections où se trouvent les données de retentions. Ne pas les modifier dans la commande.
• MONGO_DB_CONNECTION_OPTIONS : options de connexion à MongoDB. Ces options sont nécessaires si l’authentification, le chiffrement ou des paramètres spécifiques sont activés sur la base ( voir le chapitre Options de connexion à la base MongoDB ).

La commande crée les fichiers suivants :  

• retention_hosts_raw.bson
• retention_hosts_raw.metadata.json
• retention_services_raw.bson
• retention_services_raw.metadata.json

Exemple de sauvegarde

Sauvegarde de la rétention sur un MongoDB en local

Pour sauvegarder la rétention Pour sauvegarder la rétention dans deux dossiers retention_hosts_11_10_2021 et retention_services_11_10_2021  depuis un MongoDB sur le même serveur où ces les commandes sont lancées :

mongodump -d shinken -c retention_hosts_raw -o /root/retention_mongo/retention_hosts_11_10_2021
mongodump -d shinken -c retention_services_raw -o /root/retention_mongo/retention_services_11_10_2021

Sauvegarde de la rétention sur une MongoDB sur un autre serveur

Pour sauvegarder la rétention dans deux dossiers retention_hosts_11_10_2021 et retention_services_11_10_2021 depuis un MongoDB sur un serveur hébergé sur un serveur nommé host_bordeaux et où MongoDB utilise le port 27018.

mongodump -d shinken -c retention_hosts_raw -h host_bordeaux --port=27018 -o /root/retention_mongo/retention_hosts_11_10_2021
mongodump -d shinken -c retention_services_raw -h host_bordeaux --port=27018 -o /root/retention_mongo/retention_services_11_10_2021

Sauvegarde de la rétention sur une MongoDB sur un autre serveur qui utilise le SSL

Pour sauvegarder la rétention dans deux dossiers retention_hosts_11_10_2021 et retention_services_11_10_2021 depuis un MongoDB sur un serveur hébergé sur un serveur nommé host_bordeaux, où MongoDB utilise le port 27017 ( port par défaut ) et utilisant le SSL :

Exemple de retour avec succès de la commande

20212025-1006-12T1104T03:0958:12.823+020027.264-0400    writing shinken.retention_services_raw to /root/retention_hosts_11_10_2021mongo/shinken/retention_services_raw.bson
20212025-1006-12T1104T03:0958:12.823+020027.269-0400    writing shinken.retention_services_raw metadata to /root/retention_hosts_11_10_2021mongo/shinken/retention_services_raw.metadata.json
20212025-1006-12T1104T03:0958:12.825+0200    the collection shinken.retention_services_raw appears to have been dropped after the dump started
2021-10-12T11:09:12.825+020027.272-0400    done dumping shinken.retention_services_raw (4532 documents)

Si

Comment restaurer la rétention MongodbRetention

Avant de sauvegarder la rétention

Avant d'effectuer la restauration de la rétention, il est conseillé d'éteindre le Scheduler :

service shinken-scheduler stop

Détails de la commande mongorestore

La restauration des données issues de la commande mongodump se fait avec la commande mongorestore :

Pour restaurer la rétention, lancer la commande : 

mongorestore --drop --ssl -h HOST_NAME --port=HTTP_PORT RETENTION_FOLDER_PATH  /root/retention_mongo/ ( +  MONGO_DB_CONNECTION_OPTIONS )

• --drop : Permet de supprimer les collections de rétention présentes dans la base afin d’éviter toute incohérence.
• /root/retention_mongo/ :Dossier contenant la sauvegarde de la rétention, créé par la commande mongodump ( voir le chapitre mongodump ).
• MONGO_DB_CONNECTION_OPTIONS : Options de connexion à MongoDB. Nécessaire si l'authentification ou le chiffrement de la base est activé, ou si la base n'utilise pas les paramètres par défauts.

Exemple de restauration 

--drop

--ssl

-h HOST_NAME

--port=HTTP_PORT

RETENTION_FOLDER_PATH

Restauration d'une rétention sur un MongoDB en local

Cette commande va restaurer dans un MongoDB local les données contenues dans le dossier /root/retention_hosts_11_10_2021/

mongorestore --drop /root/retention_hosts_11_10_2021/

Restauration d'une rétention sur un MongoDB sur un autre serveur

mongo/ : 

Cette commande va restaurer dans un MongoDB sur un serveur nommé host_bordeaux où MongoDB utilise le port 27018 les données contenues dans le dossier /root/retention_hosts_11_10_2021/

mongorestore --drop -h host_bordeaux --port=27018 /root/retention_hosts_11_10_2021/

Restauration d'une rétention sur un MongoDB sur un autre serveur qui utilise le SSL

mongo/

Cette commande va restaurer dans un MongoDB sur un serveur nommé host_bordeaux avec le port 27018 et utilisant le SSL, les données contenues dans le dossier /root/retention_hosts_11_10_2021/

Exemple de retour avec succès d'une commande de restauration

Après la restauration de la rétention

Cas particulier de l'utilisation d'un cluster MongoDB

Si vous utilisez MongoDB en mode cluster, les commandes restent les mêmes, à la nuance près qu'il faut préciser le port du bon service.

Pour la sauvegarde et la restauration de la rétention d'un cluster MongoDB, il est recommandé de passer par le service mongos et non mongod.

Pour utiliser un service plutôt que l'autre, il suffit de trouver et utiliser son port à fournir aux commandes.

Vérifier la présence du service mongos

Trouver le port du service mongos

.metadata.json
2025-06-04T04:22:19.661-0400    restoring shinken.retention_hosts_raw from file retention_mongo/shinken/retention_hosts_raw.bson
2025-06-04T04:22:19.666-0400    restoring indexes for collection shinken.retention_services_raw from metadata
2025-06-04T04:22:19.700-0400    finished restoring shinken.retention_services_raw (32 documents)
2025-06-04T04:22:19.701-0400    restoring indexes for collection shinken.retention_hosts_raw from metadata
2025-06-04T04:22:19.702-0400    finished restoring shinken.retention_hosts_raw (2 documents) 

Si la dernière ligne du retour de la commande, il y a écrit "(0 documents)" :

• La première sauvegarde de la rétention n'a pas encore eu lieu.
  • Attendre la première sauvegarde de la rétention ( par défaut 60 minutes, voir la page Fichier de configuration ( shinken.cfg ) ) ou redémarrer le Scheduler pour la forcer. 
    
    
• Les paramètres fournis sont incorrects.
  • Vérifier le nom de la base, des collections. 
    
    
• Il y a eu une erreur lors de la sauvegarde précédente. 

Après la restauration de la rétention

Une fois la restauration terminée, il faut redémarrer le Scheduler :

service shinken-scheduler start

Le port souhaité est celui indiqué dans la section "net", dans notre exemple, ce sera le port du service mongos est 27018.

Exemples de restauration et de sauvegarde

Après avoir trouvé le port du bon service, disons 27018, il faut le renseigner aux commande de sauvegarde et de restauration :

Exemple de sauvegarde

Exemple de restauration