Rotation des log

Pour mettre en place vous même la rotation des log, il faut rajoutez deux entrées au fichier /etc/crontab


# A 3h01 on demande a mongo de rotationner son log
1 3 * * * root kill -USR1 `cat /var/run/mongodb/mongod.pid`

#A 3h02 on supprime les logs plus vieux de 7jours
2 3 * * * root find /var/log/mongodb/ -name "*.log.*" -type f -mtime +7 | xargs /bin/rm -f


Et ensuite relancer le daemon crond:

service crond reload


Surveillance du taux de fragmentation de la base

La base de données va se fragmenter au fil des insertions/suppression d'éléments, et le volume des données va devenir plus faible que le volume sur disque (dans /var/lib/mongo): c'est la fragmentation.

Il est possible de surveiller ce taux de fragmentation et même le réduire.

Un script sera prochainement disponible afin d'avoir le calcul de ce taux, avec les volumes utilisés et les volumes sur disque.


Il se lance de la manière suivante:

check_mongo_fragmentation.py -H IP_SERVEUR --connection-method=ssh --ssh-user=shinken  --ssh-keyfile=~shinken/.ssh/id_rsa
  • -H: adresse publique du serveur à vérifier
    • ou localhost si vous souhaitez vérifier le serveur sur lequel s'exécute le script
  • --connection-method=ssh: à n'utiliser que pour les serveurs distants afin de créer un tunnel ssh vers le serveur et protéger les accès
  • --ssh-user: utilisateur à utiliser pour les serveurs distants pour les connexions SSH
  • --ssh-keyfile: clé SSH à utiliser pour les serveurs distants

Il va fournir les informations suivantes:

  • Database: le nom de la base
  • Disk-usage: la consommation disque de la base
  • Data: le volume de données contenu dans la base
  • Compression-save: espace disque économisé gracve à la compression de données (seulement pour Wired Tiger)
  • Fragmented: espace non utilisé du à la fragmentation
    • cet espace peux être réutilisé pour de nouvelles données, à la discrétion du moteur
    • en cas de compactage ou migration, la majeur partie de cet espace pourra être récupéré

Exécution sur une base avec MMapV1

Sur une base avec MMapV1 l’exécution va donner un résultat suivant:

  • Le script va conseiller de migrer de moteur de données, de MMapV1 vers Wired Tiger, en demandant à se référer à la documentation (cette page)
  • Il fourni l'espace perdu à cause de la fragmentation, qui pourra être récupéré lors d'une migration
    • l'espace sera probablement encore plus grand lors de la migration, car Wired Tiger compresse les données sur disque

Exécution sur une base avec Wired Tiger

Sur une base avec Wired Tiger, le résultat sera le suivant:

  • Le script ne va conseiller un compactage de la base de données que si le pourcentage d'espace perdu est > 50%
    • dans ce cas il conseille de se référer à la documentation, cette même page.

Compactage de la base

La base de données va se fragmenter au fil des insertions/suppression d'éléments, et le volume des données va devenir plus faible que le volume sur disque (dans /var/lib/mongo). Il est possible de surveiller cet écart de consommation, et même la réduire.

Surveillance du taux 



Une fois


Compactage de la base

Deux méthodes options existent pour le compactage de la base :

  • Compactage dans la base
  • Faire une sauvegarde la base et restauration dans une autre base

La 1ere option ne nécessite pas le montage d'une autre base ni de transfèrt de donnée c'est globalement plus simple mais pendant que la base se compacte elle est indisponible ce qui peux provoquer un long temps indisponibilité. 

Une autre chose à pendre en compte : depuis la version 02.07.00 nous avons mis à jour la version de Mongo utilisé, nous sommes passé de la version V02.09 à V03.00. La version V03.00 de Mongo utilise par défaut un nouveau moteur de stockage : Wired Tiger, plus performant.
Si votre installation initiale de Shinken est antérieure à la version 02.07.00 il y a de grande chance que vous n'utilisez pas le moteur Wired Tiger mais MMAPv1. Vous pouvez vérifiez avec la commande suivante : 

mongo shinken  --quiet --eval "print(db.serverStatus().storageEngine.name)"

Si vous n'utilisiez pas le moteur Wired Tiger nous vous conseillons la méthode de transfère de donnée vers une autre base pour utiliser le moteur Wired Tiger dans la nouvelle base, ce nouveau moteur consommant moins de données et étant plus performant.


Méthode 1 : Compactage dans la base

Il est important à noter que pendant que le script va fonctionner, la base se bloquée et les opérations ne pourront pas se faire. Nous vous conseillons de faire cette opération avec Shinken éteint.

Un script sera fourni pour lancer le compactage de la base.

Méthode 2: sauvegarde/restauration de la base dans une autre base de donnée

Il est important de noter que pendant la restauration des données, il ne faut pas que Shinken fonctionne. Cette opération doit donc se faire à froid.

Afin de sauvegarder la base, il faut prévoir suffisamment d'espace disque. Il faut ensuite lancer:

shinken-backup --addons --configuration --sla --user

Restauration sur un nouveau serveur:

Il faut ensuite transférer le backup sur le nouveau serveur et lancer la restauration:

shinken-restore

Restauration sur le même serveur:

Si vous souhaitez réutiliser le même serveur, il va falloir:

  • arrêter mongo
  • supprimer ses données
  • s'assurer que le format de données est bien WiredTiger
  • restaurer les données

Arrêter mongo:

/etc/init.d/mongod stop

Supprimer les données:

rm -rf /var/lib/mongo/*

Pour s'assurer que le format de données est WiredTiger, il faut que l'entrée suivante soit dans le fichier /etc/mongod.conf:

storage:
     engine: wiredTiger

Puis relancer la base:

/etc/init.d/mongod start


Ensuite il faut lancer l'import, qui va se faire avec le nouveau format de données, et avec un espace disque consommé minimal:

shinken-restore