La méthode pour sauvegarder et restaurer manuellement la rétention dépend du type de module de rétention utilisé par vos Schedulers :
Vous trouverez plus d'information sur ces modules en suivant ces liens : |
Lorsque le module PickleRetentionFile est utilisé, la sauvegarde de la rétention se fait dans un fichier situé au chemin suivant : /var/lib/shinken/
Le nom de ces fichiers respecte ce format :
retention.dat_--_realm--REALM_NAME_--_scheduler--SCHEDULUER_NAME_--_id--SCHEDULER_ID.retention |
| Nom | Exemple | Description | |
|---|---|---|---|
| All | Nom du royaume sauvegardé dans la rétention. | |
| scheduler-master | Nom du Scheduler qui a effectué la rétention. | |
| 0 | Id du Scheduler qui a effectué la rétention. |
Exemple de nom de fichier :
retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention |
En fonction de votre configuration ( en fonction du nombre de royaumes et de Schedulers que vous avez ) il peut y avoir plusieurs fichiers dans le dossier Pensez à vérifier que vous avez sauvegardé tous les fichiers. |
Pour sauvegarder ces fichiers de rétention, il suffit de les copier à l'endroit souhaité avec la commande cp <source> <destination> :
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 nommé /root/retention_save/
|
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/
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 /root/retention_save/retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention /var/lib/shinken/ |
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 |
Après avoir restauré les fichiers de rétention, il faut redémarrer le Scheduler pour que les changements fassent effet :
service shinken-scheduler restart |
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.
Pensez à vérifier que vous n'avez pas changé le nom de la base par défaut ( shinken ), dans le cas contraire, il faudra changer le nom de la base dans la commande ( paramètre "-d" ) |
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 :
service shinken-scheduler restart |
Pour enregistrer les données de ces collections, on utilise la commande mongodump :
mongodump -d DATABASE_NAME -c COLLECTION_NAME -h HOST_NAME --poty=HTTP_PORT --ssl -o OUTPUT_NAME |
Explication des paramètres :
| Paramètre | Obligatoire | Exemple | Description | |
|---|---|---|---|---|
| Oui | shinken | Nom de la base Mongo | |
| Oui | retention_hosts_raw | Nom de la collection Mongo | |
| 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. Non nécessaire si la commande est lancée sur le même serveur. | |
| Non | 27018 | 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 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. | |
| Non | - | Si votre base MongoDB utilise le SSL, il faut ajouter cette option qui ne prend pas d'arguments. | |
| 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. |
|
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.
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 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 |
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 |
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 :
mongodump -d shinken -c retention_hosts_raw -h host_bordeaux --ssl -o /root/retention_mongo/retention_hosts_11_10_2021 mongodump -d shinken -c retention_services_raw -h host_bordeaux --ssl -o /root/retention_mongo/retention_services_11_10_2021 |
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) |
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. |
Avant d'effectuer la restauration de la rétention, il est conseillé d'éteindre le Scheduler :
service shinken-scheduler stop |
La restauration des données issues de la commande mongodump se fait avec la commande mongorestore :
mongorestore --drop --ssl -h HOST_NAME --port=HTTP_PORT RETENTION_FOLDER_PATH |
| Paramètre | Obligatoire | Exemple | Description | ||
|---|---|---|---|---|---|
| Non mais conseillé | - | Sans ce paramètre, MongoDB va tenter de garder les collections présentes actuellement dans la base, ce qui peut résulter en des mélanges de données non souhaitée. Pour retrouver la rétention au même état qu'au moment de sa sauvegarde, il faut utiliser ce paramètre.
| ||
| Non | - | Si votre base MongoDB utilise le SSL, il faut ajouter cette option qui ne prend pas d'arguments. | ||
| 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. Non nécessaire si la commande est lancée sur le même serveur. | ||
| Non | 27018 | 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 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. | ||
| Oui | /root/retention_hosts_11_10_2021/ | Chemin vers le dossier contenant la sauvegarde de la rétention qui a été créé avec la commande mongodump. Le dossier doit être sur le même serveur que celle où la commande est lancée. |
Bien qu'il soit possible d'utiliser la commande mongodump sur un mongod, la commande mongorestore doit être utilisée sur un mongos.
Pour vérifier si un mongos est sur un serveur, il est possible de vérifier en demandant le status du service mongos :
service mongos status |
Si un processus mongos tourne sur le serveur sur lequel la commande a été lancée, alors le retour de la commande devrai ressembler à ça :
● mongos.service - SYSV: Mongo is a scalable, document-oriented database.
Loaded: loaded (/etc/rc.d/init.d/mongos; bad; vendor preset: disabled)
Active: active (running) since Tue 2021-10-19 11:04:58 CEST; 53min ago
Docs: man:systemd-sysv-generator(8)
Process: 2805 ExecStart=/etc/rc.d/init.d/mongos start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/mongos.service
└─2820 /usr/bin/mongos -f /etc/mongos.conf
|
Pour restaurer la rétention, il faut aussi connaître son port HTTP. Vous pouvez le retrouver dans son fichier de configuration ( par défaut dans /etc/mongos.conf ) :
...
# network interfaces
net:
port: 27018
bindIp: 192.168.1.100
sharding:
configDB: primary:27019, secondary1:27019, secondary2:27019
... |
Le port souhaité est celui indiqué dans la partie "net", dans notre exemple, ce sera la 27018.
La commande pour restaurer la rétention ressemblerait alors à ça :
mongorestore --port=27018 --drop /root/retention_hosts_11_10_2021/ |
Ou alors si la commande est lancée depuis un autre serveur :
mongorestore --port=27018 -h 192.168.1.100 --drop /root/retention_hosts_11_10_2021/ |
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/ |
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/ |
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/
mongorestore --drop --ssl -h host_bordeaux --port=27018 /root/retention_hosts_11_10_2021/ |
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 |
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 :
service shinken-scheduler start |