Go to Hackademy website

Archiver les logs Rails en production

Nicolas Cavigneaux

Posté par Nicolas Cavigneaux dans les catégories outils

Par défaut, une application Rails ne prévoit aucun mécanisme pour archiver ses logs au fil du temps, c’est à l’administrateur système de mettre en place un système pour gérer cet archivage comme il l’entend.

Aujourd’hui très peu d’administrateurs prennent le temps de mettre en place un tel système. C’est pourtant un aspect critique de la gestion de l’application et de son bon fonctionnement à long terme sur le serveur.

En effet, si vous ne mettez pas en place un système d’archivage des logs, le fichier production.log va grossir au fil des jours et finir par atteindre une taille de plusieurs Go. Votre serveur peut donc à terme manquer d’espace ce qui vous causera toute sorte de soucis et notamment l’indisponibilité de votre application Rails.

Nous allons voir comment utiliser un outil système standard sous Linux pour gérer cet archivage. C’est l’outil logrotate que nous allons utiliser pour effectuer cette tâche de manière automatique.

Qu’est-ce que logrotate ?

Logrotate permet de limiter la taille des fichiers de log en réalisant deux opérations :

  • la rotation qui consiste à archiver le fichier de log sous un autre nom et supprimer les archives les plus anciennes
  • la compression qui permet d’économiser de l’espace disque

Logrotate va garder un certain nombre de fichiers de logs accessibles pour consultation sous forme compressée. On ne gâche donc plus d’espace disque avec de très vieux logs et ceux conservées consomment un espace disque restreint.

Il y a de très fortes chances que logrotate soit déjà installé sur votre système. Si ce n’est pas le cas, vous le trouverez à coup sûr via votre outil de gestion de paquets.

Configurer logrotate pour votre application Rails

Configurer un archivage des logs avec logrotate est très simple. C’est un outil qui existe depuis longtemps et qui est très utilisé notamment grâce à sa simplicité de mise en œuvre.

Si vous regardez votre répertoire /var/log vous noterez que vos fichiers de logs sont archivés et compressés. C’est logrotate qui se charge de ça. Ajoutons donc notre configuration pour que l’outil gère les logs de notre application.

La configuration principal de logrotate se trouve dans le fichier /etc/logrotate.conf. Il est possible d’ajouter votre configuration directement dedans mais la bonne pratique veut qu’une directive include /etc/logrotate.d soit utilisée dans ce fichier ce qui va permettre de créer un fichier de configuration par service dans le répertoire /etc/logrotate.d.

Nous allons donc suivre cette bonne pratique est créer un fichier /etc/logrotate.d/mon_app_rails :

/var/www/mon_app_rails/current/log/*.log {
  monthly
  size 1G
  missingok
  rotate 7
  compress
  delaycompress
  notifempty
  copytruncate
}

Quelques explications

Cette syntaxe me semble particulièrement facile à comprendre et à mettre en œuvre mais je vais tout de même vous expliquer à quoi sert chaque ligne :

  • la toute première ligne donne le chemin des fichiers à archiver, ici tous les .log de notre répertoire /var/www/mon_app_rails/current/log
  • monthly archive le fichier chaque mois, on peut demander à ce que ce soit chaque jour, chaque semaine ou encore chaque année
  • size 1G permet de lancer l’archivage si le fichier de log a atteint la taille de 1Go, cette condition a une précédence plus forte que monthly. On peut utiliser d’autres unités telles que k, M
  • missingok ne génère pas d’erreur si l’un des fichiers mentionné n’existe pas
  • rotate 7 permet de garder les sept derniers fichiers archivés, donc ici sept mois
  • compress demande la compression via GZip des archives
  • delaycompress ne compresse pas la toute dernière archive mais uniquement les plus anciennes pour faciliter l’analyse des logs de la période passée
  • notifempty ne crée pas d’archive si le fichier de log est vide
  • copytruncate copie le fichier de log vers son nom d’archive puis le vide ce qui permet d’éviter les problèmes avec un processus qui requière que le fichier existe avant de pouvoir écrire dedans

De nombreuses autres options existent et permettent d’avoir un contrôle très fin sur la gestion de vos logs, je vous encourage à lire le manuel de logrotate pour les découvrir.

Faire quelques tests

On peut maintenant tester notre configuration fraîchement ajoutée en lançant manuellement la commande logrotate. Elle requiert les droits root :

$ sudo /usr/sbin/logrotate -f /etc/logrotate.conf

Vous pouvez maintenant vérifier que votre archive a bien été crée dans le répertoire des logs de votre application.

Dans un mois, logrotate créera une nouvelle archive et compressera les anciennes.

Un ls dans le répertoire donnera alors quelque chose comme :

$ ls log/

production.log production.log.1 production.log.2.gz

production.log est votre fichier de log courant, utilisé par votre application Rails. production.log.1 est une copie des anciens logs (entre la première et la deuxième rotation) et production.log.2.gz est la version compressée d’une archive plus ancienne.

Quand logrotate aura créé sept archives, il commencera à supprimer les plus anciennes à chaque rotation pour ne garder que les sept plus récentes. Pour mémoire ce comportement est dû à la directive rotate 7 dans notre configuration.

Vous pouvez maintenant vérifier que le répertoire /etc/cron.daily contient bien un fichier logrotate ce qui assurera que la commande logrotate sera exécutée chaque jour :

#!/bin/sh

test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf

Si c’est le cas, vous avez l’assurance que logrotate prendra maintenant soin d’archiver automatiquement vos fichiers de logs pour vous.

Conclusion

Nous avons donc vu qu’il est extrêmement simple de mettre en œuvre une rotation de log en passant par l’outil logrotate. Cette tâche dans le contexte des applications Rails passe souvent à la trappe et c’est une vrai erreur selon moi.

Vous risquez des soucis avec votre serveur et de plus vous vous mettez des bâtons dans les roues pour le jour où vous voudrez consulter vos logs. Essayez d’ouvrir un fichier texte de 2Go et de le parcourir… Il est tout de même plus simple d’ouvrir celui correspondant au mois voulu et de faire sa recherche dans un fichier d’une centaine de Mo.

Vous n’avez plus qu’à écrire vos petits fichier de configuration logrotate maintenant !


L’équipe Synbioz.

Libres d’être ensemble.

Articles connexes

Un plugin Vim à la mimine

03/01/2019

Dans l’article précédent, intitulé une assez bonne intimité, je vous présentais GPG et le chiffrement de courriels. Nous avons alors remarqué que le contenu d’un courriel était encodé de sorte que le...

Une assez bonne intimité

20/12/2018

Si vous êtes utilisateur de MacOS, il y a de fortes chances que vous utilisiez Apple Mail pour échanger des courriels. Et comme vous êtes sensible à la confidentialité des informations que vous...

Tests end to end avec Jest et Puppeteer

05/07/2018

Dans cet article, on va partir sur des tests end to end. Pour planter le décor, un test end to end (e2e) est un test logiciel qui a pour but de valider que le système testé répond correctement à un...

Chasser les requêtes N+1 avec Bullet

05/04/2018

Aujourd’hui nous allons parler des requêtes N+1 dans une application Rails : vous savez ces lignes quasiment identiques, qui s’ajoutent de manière exponentielle aux logs, dès lors que l’on appelle...