Automatisation de la gestion des journaux avec logrotate et compression

La croissance continue des journaux peut saturer un système, compliquer les diagnostics et impacter les performances. logrotate automatise la rotation, la compression et la rétention des logs pour garder un environnement propre, traçable et performant.

Plan de l’article

• Principe de fonctionnement de logrotate
• Prérequis et emplacements clés
• Configuration de base (rotation, compression, rétention)
• Rotation par taille vs par périodicité
• Scripts prerotate / postrotate et rechargement des services
• Intégration via cron et systemd timers
• Exemples : rsyslog, Nginx, Apache, PostgreSQL
• Vérifications, tests et forçage de rotation
• Bonnes pratiques et ressources

Prérequis

• Système Linux (Debian/Ubuntu/…)
• Paquet logrotate installé
• Accès root pour éditer /etc/logrotate.conf et /etc/logrotate.d/*

Fonctionnement

• Rotation : le fichier courant est renommé (.1, .2.gz, …) et un nouveau fichier est créé si nécessaire.
• Compression : réduction d’espace via compress (gzip par défaut), avec support de delaycompress.
• Rétention : conservation d’un nombre défini de versions (rotate N).
• Scripts : hooks prerotate / postrotate pour recharger un service ou exécuter des actions.

Emplacements clés :

• Configuration globale : /etc/logrotate.conf
• Règles par service : /etc/logrotate.d/<service>

Configuration de base

Exemple (rsyslog – Debian) dans /etc/logrotate.d/rsyslog :

/var/log/syslog
/var/log/auth.log
/var/log/kern.log
/var/log/daemon.log
/var/log/user.log
/var/log/mail.log
{
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    su root adm
    create 0640 syslog adm
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

• daily : rotation quotidienne
• rotate 7 : conserver 7 archives
• compress + delaycompress : compresser à la rotation suivante (évite de compresser un fichier potentiellement encore ouvert)
• create : recréer le fichier avec droits et propriétaire adaptés
• postrotate : notifier rsyslog pour rouvrir les fichiers

Rotation par taille vs par périodicité

• Par périodicité (daily, weekly, monthly) : simple, prévisible.
• Par taille (size 100M, minsize 1M) : utile pour des logs très bavards.
• Possibilité de combiner : la rotation se fait si l’un des critères est atteint.

Exemple :

/var/log/monappli/*.log {
    size 200M
    rotate 10
    compress
    missingok
    notifempty
    copytruncate
}

copytruncate duplique puis tronque le fichier sans signaler l’application (utile si elle ne sait pas rouvrir le descripteur). Préférer un reload quand c’est possible.

Scripts prerotate / postrotate

• prerotate : actions avant la rotation (ex. flush applicatif).
• postrotate : rechargements de services pour rouvrir les fichiers.

Exemple :

/var/log/app/*.log {
    weekly
    rotate 8
    compress
    missingok
    notifempty
    postrotate
        systemctl reload app.service >/dev/null 2>&1 || true
    endscript
}

Intégration (cron vs systemd)

• Historiquement, cron lance /etc/cron.daily/logrotate.
• Sous systemd, un timer peut exécuter logrotate (unités logrotate.service et logrotate.timer).
• Vérifier la présence du timer : systemctl status logrotate.timer.

Exemples par service

Nginx

/var/log/nginx/*.log {
    weekly
    rotate 12
    compress
    missingok
    notifempty
    sharedscripts
    postrotate
        [ -s /run/nginx.pid ] && kill -USR1 "$(cat /run/nginx.pid)"
    endscript
}

kill -USR1 demande à Nginx de rouvrir les fichiers log proprement.

Apache (HTTPd)

/var/log/apache2/*.log {
    weekly
    rotate 12
    compress
    missingok
    notifempty
    sharedscripts
    postrotate
        systemctl reload apache2 >/dev/null 2>&1 || true
    endscript
}

PostgreSQL

PostgreSQL possède sa propre rotation via log_rotation_age, log_rotation_size et un log_filename daté. Deux approches :

1. Native PostgreSQL (recommandé) : gérer la rotation dans postgresql.conf.
2. logrotate (si nécessaire) : utiliser copytruncate et/ou un reload :

/var/log/postgresql/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    copytruncate
    postrotate
        systemctl reload postgresql >/dev/null 2>&1 || true
    endscript
}

Vérifier, tester, forcer

• Vérification (dry-run) : logrotate -d /etc/logrotate.conf
• Verbosité : logrotate -v /etc/logrotate.conf
• Forcer une rotation : logrotate -f /etc/logrotate.conf
• État interne : consulter /var/lib/logrotate/status

Bonnes pratiques

• Adapter la rétention aux obligations légales et aux besoins d’audit.
• Utiliser delaycompress quand les services écrivent encore après rotation.
• Préférer un reload de service à copytruncate lorsque possible.
• Surveiller l’espace disque (df, du) et alerter (Prometheus/Alertmanager, Icinga, etc.).
• Centraliser les logs critiques (Loki/ELK) pour la recherche, la rétention longue et l’archivage.

Ressources

• man logrotate, man logrotate.conf
• Documentation Nginx / Apache sur la rotation des journaux
• Bonnes pratiques de journalisation et centralisation (Loki, Elasticsearch)

Conclusion

Avec une configuration soignée et des hooks adaptés, logrotate garantit une gestion fiable, peu coûteuse et traçable des journaux. La combinaison rotation + compression + rétention protège l’espace disque, simplifie les analyses et renforce l’observabilité de vos systèmes.