Versions Compared

Old Version 21

changes.mady.by.user Julien Pilleux

Saved on

compared with

New Version 22

changes.mady.by.user Julien Pilleux

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Scroll Ignore
scroll-pdftrue
scroll-officetrue
scroll-chmtrue
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-epubtrue
scroll-htmltrue


Panel
titleSommaire

Table of Contents
stylenone



Description

La méthode pour sauvegarder et restaurer manuellement la rétention dépend du type de module de rétention utilisé par vos Schedulers :


Info

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


Anchor
savePickleRetention
savePickleRetention
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é au chemin suivant : /var/lib/shinken/

Le nom de ces fichiers respecte ce format :

Code Block
retention.dat_--_realm--REALM_NAME_--_scheduler--SCHEDULUER_NAME_--_id--SCHEDULER_ID.retention


NomExempleDescription


Code Block
REALM_NAME


AllNom du royaume sauvegardé dans la rétention.


Code Block
SCHEDULER_NAME


scheduler-masterNom du Scheduler qui a effectué la rétention.


Code Block
SCHEDULER_ID


0Id du Scheduler qui a effectué la rétention.


Exemple de nom de fichier : 


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


Info

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 /var/lib/shinken/

Pensez à vérifier que vous avez sauvegardé tous les fichiers.


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 nommé /root/retention_save/

Info
  • Le dossier de destination /root/retention_save/ doit exister avant de lancer la commande.
  • Le dossier de destination /root/retention_save/ n'est qu'un exemple, choisissez où bon vous semble.


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 : /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 :

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.


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 :

Code Block
service shinken-scheduler restart


Anchor
saveMongodbRetention
saveMongodbRetention
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 ), dans le cas contraire, il faudra changer le nom de la base dans la commande ( paramètre "-d" )


Comment sauvegarder la rétention MongodbRetention

Avant de lancer la sauvegarde

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


Anchor
mongodumpCommand
mongodumpCommand
Détails de la commande mongodump

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 -poty=HTTP_PORT --ssl -o OUTPUT_NAME


Explication des paramètres :

ParamètreObligatoireExempleDescription


Code Block
-d DATABASE_NAME


OuishinkenNom de la base Mongo


Code Block
-c COLLECTION_NAME


Ouiretention_hosts_rawNom de la collection Mongo


Code Block
-h HOST_NAME


Non192.168.1.25Adresse 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.


Code Block
--
p 
port=HTTP_PORT


Non
4567
27018

Port HTTP

du serveur où se trouve

de 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.

  ( 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.


Code Block
--ssl


Non-Si votre base MongoDB utilise le SSL, il faut ajouter cette option
Code Block
--ssl
Non-Si votre base MongoDB utilise le SSL, il faut ajouter cette option
qui ne prend pas d'arguments.


Code Block
-o OUTPUT_NAME


Nonretention_hosts_11_10_2021Nom 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.



Info
  • Pour savoir quels paramètres utiliser, vous pouvez vous référer au fichier de configuration de votre Scheduler, par défaut ici : /etc/shinken/schedulers/scheduler-master.cfg
  • Il est possible d'utiliser plusieur plusieurs fois le même OUTPUT_NAME, les données seront alors toutes sauvegardées dans le même dossier et donc peuvent être toutes restaurées avec qu'une seule commande mongorestore.
  • Si vous utilisez MongoDB en cluster, il est possible d'utiliser la commande mongodump avec n'importe lequel des processus MongoDB ( mongod ou mongos ). Il faut juste préciser le port de celui que vous voulez utiliser avec le paramètre --port.


Ces deux commandes vont créer deux dossiers à l'emplacement /root/retention_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

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 :

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


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 avec le port 4679 : et où MongoDB utilise le port 27018.

Code Block
mongodump -d shinken -c retention_hosts_raw -h host_bordeaux --pport=27018 4679 -o /root/retention_mongo/retention_hosts_11_10_2021
mongodump -d shinken -c retention_services_raw -h host_bordeaux -p 4679 -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 avec le port 4679 et , où MongoDB utilise le port 27017 ( port par défaut ) et utilisant le SSL :

Code Block
mongodump -d shinken -c retention_hosts_raw -h host_bordeaux -p 4679 --ssl -o /root/retention_mongo/retention_hosts_11_10_2021
mongodump -d shinken -c retention_services_raw -h host_bordeaux -p 4679 --ssl -o /root/retention_mongo/retention_services_11_10_2021


Exemple de retour avec succès de la commande


Code Block
themeEmacs
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.


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 :


Code Block
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 :

Code Block
mongorestore --drop --ssl -h HOST_NAME -p -port=HTTP_PORT RETENTION_FOLDER_PATH


ParamètreObligatoireExempleDescription


Code Block
--drop


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.

Warning

Ce paramètre va effacer la rétention acutellement présente en base.



Code Block
--ssl


Non-Si votre base MongoDB utilise le SSL, il faut ajouter cette option qui ne prend pas d'arguments.


Code Block
-h HOST_NAME


Non192.168.1.25Adresse 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.


Code Block
--
p 
port=HTTP_PORT


Non
4567Port HTTP du serveur 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.
Code Block
RETENTION_FOLDER_PATH
Oui
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 /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.


Code Block
RETENTION_FOLDER_PATH


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.


Cas de l'utilisation d'un cluster MongoDB

Bien qu'il soit possible d'utiliser la commande mongodump sur un mongod, la commande mongorestore doit être utilisée sur un mongos.

Trouver mongos

Pour vérifier si un mongos est sur un serveur, il est possible de vérifier en demandant le status du service mongos :

Code Block
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 :

Code Block
● 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


Restaurer la rétention avec mongos

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 ) :

Code Block
...

# 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 :


Code Block
mongorestore --port=27018 --drop /root/retention_hosts_11_10_2021/


Ou alors si la commande est lancée depuis un autre serveur :


Code Block
mongorestore --port=27018 -h 192.168.1.100 --drop /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.

Quelques exemples de commandes de restauration
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/
 Code Block
mongorestore --drop /root/retention_hosts_11_10_2021/

Restauration d'une rétention sur un MongoDB sur un autre serveur
Cette commande va restaurer dans un MongoDB sur un serveur nommé host_bordeaux avec le port 4679 les où MongoDB utilise le port 27018 les données contenues dans le dossier /root/retention_hosts_11_10_2021/
 Code Block
mongorestore --drop -h host_bordeaux -p 4679 -port=27018 /root/retention_hosts_11_10_2021/

Restauration d'une rétention sur un MongoDB sur un autre serveur qui utilise le SSL
Cette commande va restaurer dans un MongoDB sur un serveur nommé host_bordeaux avec le port 4679 et utilisant port 27018 et utilisant le SSL, les données contenues dans le dossier /root/retention_hosts_11_10_2021/
 Code Block
mongorestore --drop --ssl -h host_bordeaux -p 4679--port=27018 /root/retention_hosts_11_10_2021/

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

 Code Block
themeEmacs
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 )

Après la restauration de la rétention
Une fois la restauration terminée, vous pouvez redémarrer le Scheduler :
 Code Block
service shinken-scheduler start