| Scroll Ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Description
En fonction du type du module de rétention utilisé par votre ( ou vos ) Schedulers, il y a deux méthodes pour sauvegarder et restaurer la rétention :
- PickleRetentionFile : Module PickleRetentionFile ( Rétention par fichier plat )
- MongodbRetention : Module MongodbRetention ( Rétention en base de donnée 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 dans un fichier situé à la destination suivante : /var/lib/shinken/
Les fichiers de rétention sont nommés en suivant ce format :
| Code Block |
|---|
retention.dat_--_realm--REALM_NAME_--_scheduler--SCHEDULUER_NAME_--_id--SCHEDULER_ID.retention |
Avec :
| Nom | Exemple | Description |
|---|---|---|
| REALM_NAME | All | Nom du royaume |
| SCHEDULER_NAME | scheduler-master | Nom du Scheduler |
| SCHEDULER_ID | 0 | Id du Scheduler |
Exemple de fichier :
| Code Block |
|---|
retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention |
| Info |
|---|
Il peut y avoir plusieurs fichiers de rétention dans /var/lib/shinken/ si vous avez plusieurs royaumes et / ou plusieurs Schedulers. Pensez à vérifier que vous les avez tous sauvegardés. |
Comment sauvegarder la rétention Pickle
Pour sauvegarder ces fichiers de rétention, il suffit de les copier à l'endroit souhaité avec la commande cp <source> <destination> :
| Code Block |
|---|
cp /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 /root/retention_save/
| Info |
|---|
|
Comment restaurer la rétention Pickle
Pour restaurer un fichier de rétention Pickle, il suffit de le remettre à l'endroit depuis lequel ils ont été copiés : /var/lib/shinken/
| Code Block |
|---|
cp /root/retention_save/retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention /var/lib/shinken/ |
| Warning |
|---|
Attention, la commande cp écrase la destination ! 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. |
Sauvegarde et restauration de la rétention avec le module MongodbRetention
Où se trouve la rétention dans Mongo
Avec le module MongodbRetention, la rétention se trouve dans la base shinken ( par défaut ) dans les collections retention_hosts_raw et retention_services_raw.
| Note |
|---|
Pensez à vérifier que vous n'avez pas changé le nom de la base par défaut ( shinken ) |
Comment sauvegarder la rétention MongodbRetention
Avant de sauvegarder la rétention, il est conseillé ( si possible ) de redémarrer le Scheduler afin de forcer la rétention, et donc d'avoir des données plus fraiches :
| Code Block |
|---|
service shinken-scheduler restart |
Cas d'un Mongo en local
Pour enregistrer les données de ces collections, on utilise la commande mongodump :
| Code Block |
|---|
mongodump -d DATABASE_NAME -c COLLECTION_NAME -h HOST_NAME -p HTTP_PORT -o OUTPUT_FOLDER_NAME |
Avec Explication des paramètres :
| Paramètre | Obligatoire | NomExemple | Description | ||
|---|---|---|---|---|---|
| Oui | shinken | Nom de la base Mongo | ||
| -c COLLECTION_NAME | Oui | retention_hosts_raw | Nom de la collection Mongo | ||
| -h HOST_NAME | Non | 192.168.1.25 | Adresse IP ou nom de l'hôte où se trouve la base MongoDB utilisée par le Scheduler pour sauvegarder sa rétention | ||
| -o OUTPUT_FOLDER_NAME | Non | retention_hosts_11_10_2021 | Nom du fichier de sortie de la commande. Ce paramètre est optionnel mais nous vous recommandons de donner un nom parlant au dossier créé par mongodump. Si ce paramètre n'est pas renseigné, alors le dossier sera nommé dump. |
Exemple de commandes :
| Code Block |
|---|
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 |
Ces deux commandes vont créer deux dossiers à l'emplacement /root/retention_mongo/ ( assurez vous que ce chemin existe ) nommé retention_hosts_11_10_2021 et retention_services_11_10_2021 contenant des fichier .json et .bson qui contiennent les données des collections correspondantes.
Exemple de retour avec succès de la commande :
| Code Block | ||
|---|---|---|
| ||
2021-10-12T11:09:12.823+0200 writing shinken.retention_services_raw to /root/retention_hosts_11_10_2021/shinken/retention_services_raw.bson 2021-10-12T11:09:12.823+0200 writing shinken.retention_services_raw metadata to /root/retention_hosts_11_10_2021/shinken/retention_services_raw.metadata.json 2021-10-12T11:09:12.825+0200 the collection shinken.retention_services_raw appears to have been dropped after the dump started 2021-10-12T11:09:12.825+0200 done dumping shinken.retention_services_raw (45 documents) |
| Note |
|---|
Si sur la dernière ligne du retour de la commande, il y a écrit "(0 documents)", alors il y a peut-être un problème quelque part, comme le nom de la collection qui n'est pas correcte. |
Cas d'une base MongoDB à distance
Si la base MongoDB utilisée par le Scheduler se trouve sur un autre server, alors il faut préciser dans la commande comment s'y connecter :
| Code Block |
|---|
mongodump -d DATABASE_NAME -c COLLECTION_NAME -o OUTPUT_FOLDER_NAME |
Comment restaurer la rétention MongodbRetention
Avant d'effectuer la restauration de la rétention, il est conseillé d'éteindre le Scheduler :
| Code Block |
|---|
service shinken-scheduler stop |
La restauration des données issues de la commande mongodump se fait avec la commande mongorestore :
| Code Block |
|---|
mongorestore --drop RETENTION_FOLDER_PATH |
Il faut préciser à cette commande le dossier créé par la commande mongodump.
| Warning |
|---|
Ces commandes vont effacer toutes données de rétention actuellement présentes en base. |
Exemple de commandes :
| Code Block |
|---|
mongorestore --drop /root/retention_mongo/retention_hosts_11_10_2021 mongorestore --drop /root/retention_mongo/retention_services_11_10_2021 |
Exemple de retour avec succès de la commande :
| Code Block | ||
|---|---|---|
| ||
2021-10-12T11:11:01.024+0200 building a list of dbs and collections to restore from /root/retention_hosts_11_10_2021/ dir 2021-10-12T11:11:01.026+0200 reading metadata file from /root/retention_hosts_11_10_2021/shinken/retention_services_raw.metadata.json 2021-10-12T11:11:01.026+0200 restoring shinken.retention_services_raw from file /root/retention_hosts_11_10_2021/shinken/retention_services_raw.bson 2021-10-12T11:11:01.027+0200 finished restoring shinken.retention_services_raw (45 documents) 2021-10-12T11:11:01.027+0200 done |
| Note |
|---|
Si sur l'avant dernière ligne du retour de la commande, il y a écrit "(0 documents)", alors il y a peut-être un problème quelque part, comme la commande mongodump qui s'est mal passée ( nom de collection incorrect par exemple ) |
Une fois la restauration terminée, vous pouvez redémarrer le Scheduler :
| Code Block |
|---|
service shinken-scheduler start |