Mongodb - bonne façon de faire tourner les journaux

Mongo docs dit que je peux:

1. utiliser le signal -SIGUSR1 et obtenir l'ancien journal renommé et le courant commuté
2. utiliser logrotate à partir du système d'exploitation

Je veux que la capacité de rotation du système d'exploitation du système d'exploitation pour compresser les anciens fichiers et supprimer les plus anciens, mais ne vois aucun moyen de dire au processus mongod de basculer le journal actuel autre que l'envoi de SIGUSR1.

J'ai donc écrit

/var/log/mongodb/*.log {
    daily
    rotate 5
    compress
    dateext
    missingok
    notifempty
    sharedscripts
    postrotate
        /usr/bin/killall -SIGUSR1 mongod
        /usr/bin/killall -SIGUSR1 mongos
    endscript
}

à /etc/logrotate.d/mongo.

Et maintenant, obtenez des fichiers journaux bien nommés à partir de logrotate et des fichiers journaux vides comme des mongodb.log.2013-09-18T23-49-44traces de commutation SIGUSR1. Comment se débarrasser de ce dernier?

copytruncate fonctionne plutôt bien pour logrotation.

une configuration similaire à celle-ci devrait faire le travail pour vous:

/var/log/mongodb/*.log {
  daily
  missingok
  rotate 5
  compress
  dateext
  delaycompress
  copytruncate
  notifempty
}

Le serveur s'est bloqué pour moi si vous envoyez SIGUSR1 à mongod après avoir déplacé le fichier journal avec logrotate.

La configuration suivante est sûre pour la version que j'ai testée - 2.6.6 sur ubuntu 12.04 - les exemples précédents ont planté le serveur. Mettez ceci dans /etc/logrotate.d/mongod:

/var/log/mongodb/mongodb.log {
    weekly
    missingok
    rotate 4
    compress
    notifempty
    create
    postrotate
        /usr/bin/pkill -USR1 mongod
        rm /var/log/mongodb/mongodb.log.????-??-??T??-??-??
    endscript
}

Voir: https://jira.mongodb.org/browse/SERVER-11087 pour plus de détails et une suggestion d'Akshay Kumar que j'ai utilisée dans ce qui précède (utilisez create au lieu de nocreate et cp / dev / null dans le fichier journal).

Dans les versions ultérieures, il est censé y avoir une option logRotate que vous pouvez utiliser pour rouvrir le fichier - pas le renommer - qui contournera le problème de renommage - mais cela n'a pas fonctionné dans ma version (elle n'était pas prise en charge).

Voir: https://github.com/mongodb/mongo/commit/616461d294bd9f5054ca38b302b6fc5d70fde20c

Je l'ai testé avec

logrotate -v -f /etc/logrotate.d/mongod

Depuis mongodb 3.0, vous pouvez changer le comportement de mongodb avec le paramètre logRotate, changez dans /etc/mongod.conf

systemLog:
  logAppend: true
  logRotate: reopen

Voir aussi Mongo Manuals .

Ensuite, vous pouvez utiliser cette configuration logrotate:

/var/log/mongodb/*.log {
    daily
    rotate 30
    size 50M
    compress
    dateext
    missingok
    notifempty
    sharedscripts
    postrotate
        /bin/kill -SIGUSR1 `cat /var/lib/mongodb/mongod.lock 2> /dev/null` 2> /dev/null || true
    endscript
}

Ce qui suit a fonctionné pour moi:

/var/log/mongo/mongod.log {
    missingok
    rotate 3
    size 100M
    nodateext
    postrotate
            /usr/bin/kill -USR1 $(cat /var/run/mongod.pid)
            rm -f /var/log/mongo/mongod.log.[0-9][0-9][0-9][0-9]-*
    endscript
}

Remarques:

• Testé sur RedHat 6.5
• La seule façon d'obtenir une solution de travail était de supprimer les fichiers journaux vides produits par Mongo
• L'emplacement du fichier de verrouillage dépend de la façon dont MongoDB a été installé
• killest un Bash intégré mais logrotate fonctionne sous /bin/sh- qui ne reconnaît pas SIGUSR1sur RedHat 6.5
• Je n'ai pas testé avec compressmais ça devrait être un ajout direct

Notez que dans la version 3.0 et supérieure, il n'est pas nécessaire de tuer votre démon de base de données simplement pour faire pivoter un journal. Consultez la documentation ici:

https://docs.mongodb.com/manual/tutorial/rotate-log-files/