Pourquoi journald

Quand j’ai commencé à patouiller mes premiers serveurs, j’ai regardé un peu les bonnes pratiques et tout le monde était d’accord pour dire qu’il fallait utiliser un système de rotation de logs (souvent logrotate) pour gérer ses logs (pour ne pas qu’ils grossissent à l’infini, pouvoir virer les plus anciens, compresser les moins récents, …).

Quand j’ai commencé à régler mes premiers services (Apache, Postfix, …) je me suis vite rendu compte que, même si ça partait d’une bonne idée, c’était un sacré merdier à gérer correctement. Je m’explique.

logrotate va “rotater” les logs régulièrement. En gros, cette opération revient à déplacer le log /var/log/truc vers /var/log/truc.date puis recréer un /var/log/truc vide. Oui mais que se passe-t-il si le process n’est pas au courant de ça et qu’il continue à écrire comme un con dans l’ancien fichier de logs (le file descriptor étant toujours lié à l’ancien fichier même s’il a été renommé) ? Pas cons, les types de logrotate ont trouvé une parade : logrotate envoit un signal au process une fois le rotate fait pour qu’il ferme son file descriptor (qui est sur le fichier /var/log/truc.date) et qu’il le réouvre sur /var/log/truc. Sauf que bien évidemment, étant donné que c’est aux développeurs d’applications d’implémenter cette feature, y’a de fortes chances pour que ça ne soit pas fait ou mal fait.

Du coup les types de logrotate ont trouvé une autre solution : copytruncate. Cette option fait savoir à logrotate qu’au lieu de déplacer le fichier de logs, il le copie ailleurs et le remet à zéro une fois l’opération terminée (le fichier /var/log/truc ne change donc jamais de place). Avantage : toutes les applications sont compatibles. Inconvénient : si la copie prend un peu de temps et que le process écrit des logs pendant ce temps, ces logs sont perdus.

Si on résume les deux solutions : elles ont toutes les deux un défaut. Du coup, si on veut un truc qui marche à chaque fois et dans lequel on peut avoir confiance, on est baisés.

Journald, notre sauveur

Les types qui ont créé systemd ont aussi créé un genre de syslog : journald. C’est un démon dans lequel on envoie ses logs en vrac et il se démerde pour organiser tout ça.

Alors on va commencer directement par les inconvénients (enfin, l’inconvénient) : c’est du binaire. Tout ce que vous envoyez dans journald est stocké dans des fichiers binaires. Finis les grep 'truc' /var/log/truc et autres tail -f /var/log/truc. Si vous ne connaissez pas journalctl, vous ne pouvez rien faire. Par contre, quand vous le connaissez, tout un monde s’ouvre à vous (et un monde de ouf).

Utliser journalctl

• pour voir tous les logs depuis la nuit des temps : journalctl.
• pour voir tous les logs du service (du “unit”) truc : journalctl -u truc.
• pour voir tous les logs depuis le boot : journalctl -b.
• pour voir toutes les fois où votre machine a booté : journalctl --list-boots.
• pour voir tous les logs depuis 3 jours : journalctl --since 'yyyy-mm-dd hh:mm:ss' ou journalctl --since '3d ago' (même fonctionnement avec --until).
• pour voir tous les logs en temps réel (équivalent de tail -f) : journalctl -f.
• pour voir tous les logs du kernel (uniquement) : journalctl -k.
• pour voir tous les logs d’erreur : journalctl -p 'err' (valeurs possibles : emerg, alert, crit, err, warning, notice, info, debug).
• pour voir les 10 dernières lignes de log (équivalent de tail -n 10) : journalctl -n 10.
• pour voir la place occupée par les logs : journalctl --disk-usage.
• pour réduire la taille des logs à 500 Mo d’espace disque (les plus anciennes entrées seront supprimées jusqu’à arriver à 500 Mo de taille totale) : journalctl --vacuum-size=500M.
• pour faire en sorte que les logs de plus d’un an soient supprimés : journalctl --vacuum-time=1years.

Et bien évidemment, vous pouvez combiner ces options : pour afficher tous les logs d’erreur d’Apache entre les dates A et B : journalctl -u apache -p err --since 'AAAA-AA-AA' --until 'BBBB-BB-BB'. C’est quand même plus pratique qu’avec des grep non ?

Configurer journald

Le fichier de conf de journald est /etc/systemd/journald.conf. Voici quelques option intéressantes pour configurer la rotation et la durée de rétention :

1Storage = persistent     # Force la création de /var/log/journal contrairement à "auto"
2Compress = yes           # Activé par défaut, force la compression des entrées trop volumineuses
3SystemMaxUse = 10G       # Ne consomme pas plus de 10 Gio d'espace disque au total pour les logs
4MaxFileSec = 1month      # Valeur par défaut, rotate les logs tous les mois
5MaxRetentionSec = 1year  # Supprime les logs de plus d'un an

Une fois configuré : systemctl reload systemd-journald pour recharger la config.