Gérer ses logs sur un VPS : journalctl et logrotate

Les journaux Linux sont indispensables pour comprendre un incident, diagnostiquer un service qui refuse de démarrer et repérer une activité suspecte. Sur un VPS moderne, une partie importante de ces événements est collectée par le journal de systemd et consultable avec journalctl.

Ces données ont toutefois un coût : elles occupent de l’espace disque. Sans limite ni rotation, quelques fichiers très bavards peuvent remplir une partition. Un disque plein peut empêcher les applications d’écrire, bloquer une base de données, perturber les mises à jour et rendre certains services indisponibles.

Une gestion saine combine donc trois actions : consulter efficacement les événements, limiter leur conservation et surveiller l’espace disponible. Voici comment utiliser journalctl, configurer journald et mettre en place logrotate sur un VPS Linux.

Lire les logs systemd avec journalctl

La commande suivante affiche l’ensemble des événements accessibles dans le journal systemd :

sudo journalctl

La sortie peut être volumineuse. Pour ouvrir directement les dernières lignes, utilisez -e :

sudo journalctl -e

L’option -u filtre les événements associés à une unité systemd, comme Nginx, SSH ou une application personnalisée :

sudo journalctl -u nginx.service
sudo journalctl -u ssh.service
sudo journalctl -u monapp.service

Selon la distribution, le service SSH peut s’appeler ssh.service ou sshd.service. Vérifiez son nom avant de conclure à une absence de logs.

Pour suivre les nouveaux événements en temps réel, ajoutez -f :

sudo journalctl -u nginx.service -f

Cette commande est particulièrement utile pendant un redémarrage, un déploiement ou la reproduction d’une erreur.

Les options --since et --until limitent la recherche à une période :

sudo journalctl --since "2026-08-11 08:00:00"
sudo journalctl --since "1 hour ago"
sudo journalctl --since today --until "2026-08-11 12:00:00"

Vous pouvez également filtrer selon la priorité avec -p. Pour ne voir que les erreurs et les événements plus graves :

sudo journalctl -p err

L’option -b cible le démarrage courant. -b -1 affiche le démarrage précédent, ce qui aide à analyser un plantage suivi d’un redémarrage :

sudo journalctl -b
sudo journalctl -b -1

Enfin, -x ajoute des explications lorsqu’elles sont disponibles :

sudo journalctl -xe

Ces indications donnent du contexte, mais elles ne remplacent pas l’analyse du message original et de la configuration du service.

Exemples concrets avec journalctl

Pour afficher les erreurs récentes du système :

sudo journalctl -p err --since "30 minutes ago"

Pour consulter la fin des logs Nginx et suivre les nouveaux événements :

sudo journalctl -u nginx.service -e
sudo journalctl -u nginx.service -f

Pour surveiller SSH en temps réel :

sudo journalctl -u ssh.service -f

Pour rechercher les tentatives d’authentification refusées depuis le début de la journée :

sudo journalctl -u ssh.service --since today | grep -Ei 'failed|failure|invalid user'

Une distribution utilisant sshd.service nécessitera cette variante :

sudo journalctl -u sshd.service --since today | grep -Ei 'failed|failure|invalid user'

Pour examiner un créneau précis pendant lequel une panne a été signalée :

sudo journalctl --since "2026-08-11 14:00:00" --until "2026-08-11 14:30:00"

Associez les filtres pour réduire le bruit :

sudo journalctl -u nginx.service -p err --since "2 hours ago"

Maîtriser la taille du journal systemd

Journald peut conserver des événements en mémoire ou sur disque. Pour connaître l’espace actuellement utilisé :

sudo journalctl --disk-usage

Sa configuration principale se trouve dans /etc/systemd/journald.conf. Deux directives permettent de contrôler la croissance du journal :

[Journal]
SystemMaxUse=1G
MaxRetentionSec=30day

SystemMaxUse fixe l’espace maximal utilisé par le journal persistant. MaxRetentionSec limite la durée de conservation. Les bonnes valeurs dépendent de la taille du disque, du volume généré et des besoins d’audit. Une limite de 1 Go ne convient pas automatiquement à tous les VPS.

Après modification, redémarrez journald :

sudo systemctl restart systemd-journald

Pour libérer manuellement de l’espace, conservez seulement un volume donné :

sudo journalctl --vacuum-size=500M

Ou supprimez les journaux archivés plus anciens qu’une durée définie :

sudo journalctl --vacuum-time=14d

Une rotation préalable permet d’archiver le fichier actif avant le nettoyage :

sudo journalctl --rotate
sudo journalctl --vacuum-time=14d

Le nettoyage manuel répond à une urgence ponctuelle. Des limites permanentes dans journald.conf restent préférables pour éviter que le problème revienne.

Comprendre les fichiers de /var/log

Toutes les applications n’écrivent pas uniquement dans journald. Nginx, Apache, les bases de données et de nombreuses applications produisent des fichiers dans /var/log.

Exemples courants :

/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/apache2/access.log
/var/log/apache2/error.log
/var/log/monapp/application.log

Les logs d’accès web peuvent croître rapidement sur un service exposé. Une application qui répète une exception plusieurs fois par seconde peut également remplir un disque en quelques heures. Journald et les fichiers classiques doivent donc être surveillés séparément.

Faire tourner les fichiers avec logrotate

logrotate automatise la rotation des fichiers de logs. Il peut renommer le fichier courant, compresser les anciennes versions et supprimer les archives dépassant la rétention définie.

La configuration globale se trouve généralement dans /etc/logrotate.conf. Les services ajoutent leurs règles dans /etc/logrotate.d/. Cette organisation permet de gérer chaque application indépendamment.

Une rotation ne corrige pas une application anormalement bavarde. Elle empêche cependant ses archives de croître sans limite et réduit le risque de saturation.

Écrire une configuration logrotate pour son application

Supposons qu’une application écrive dans /var/log/monapp/application.log. Créez /etc/logrotate.d/monapp avec cette configuration :

/var/log/monapp/application.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

daily déclenche une rotation quotidienne. rotate 14 conserve quatorze anciennes versions. compress compresse les archives et delaycompress reporte la compression d’un cycle. missingok évite une erreur si le fichier est absent. notifempty ignore les fichiers vides.

copytruncate copie le contenu, puis vide le fichier original. Cette méthode convient aux applications incapables de rouvrir leur fichier de log, mais elle peut perdre quelques lignes pendant l’opération. Lorsque l’application sait rouvrir ses logs, une rotation avec rechargement est plus fiable :

/var/log/monapp/application.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 monapp monapp
    postrotate
        systemctl reload monapp.service >/dev/null 2>&1 || true
    endscript
}

N’utilisez pas copytruncate dans cette seconde variante. Vérifiez aussi que le service prend réellement en charge reload. Sinon, adoptez la méthode recommandée par l’application.

Tester logrotate sans surprise

Avant d’activer une nouvelle règle, lancez un test à blanc :

sudo logrotate -d /etc/logrotate.conf

Le mode -d affiche les décisions sans effectuer la rotation. Contrôlez les chemins, les permissions, la fréquence et les éventuelles erreurs de syntaxe.

Pour forcer une rotation pendant une validation :

sudo logrotate -f /etc/logrotate.conf

Cette commande modifie réellement les fichiers. Utilisez-la après le test à blanc, puis vérifiez que l’application continue d’écrire dans le bon fichier et que les archives attendues ont été créées.

Surveiller l’espace disque

La rotation doit être complétée par une surveillance régulière. Pour afficher l’occupation des partitions :

df -h

Pour identifier les répertoires les plus volumineux dans /var/log :

sudo du -h -d 1 /var/log

Pour trier les éléments du plus petit au plus grand :

sudo du -h -d 1 /var/log | sort -h

Mettez en place une alerte avant la saturation, par exemple à 80 % ou 90 % selon la capacité et la vitesse de croissance. Attendre 100 % est risqué : les services peuvent échouer avant même qu’un administrateur ait le temps d’intervenir. Un outil comme Netdata peut alerter automatiquement avant la saturation.

Respecter le RGPD dans les logs

Les journaux peuvent contenir des données personnelles, notamment des adresses IP, des identifiants de compte ou des informations liées à une requête. Leur conservation doit répondre à un objectif précis et rester limitée à une durée justifiable.

Restreignez l’accès aux administrateurs concernés, protégez les archives et évitez d’enregistrer des mots de passe, jetons d’API, cookies de session ou contenus sensibles. Vérifiez également les sauvegardes et les systèmes de centralisation, car supprimer un fichier local ne supprime pas forcément ses copies.

Pour un hébergement en France, une infrastructure adaptée facilite la maîtrise de la localisation des données. TalCloud s’inscrit dans ce cadre avec des serveurs en France, une approche RGPD, du stockage NVMe, une protection Anti-DDoS Netrix et un support humain. Ses offres VPS démarrent à 4,99 € par mois.

Bonnes pratiques à retenir

Configurez une rotation dès la mise en production, compressez les archives et choisissez une rétention cohérente avec vos besoins techniques et réglementaires. Contrôlez à la fois journald et les fichiers de /var/log, car ils suivent des mécanismes distincts.

Sur plusieurs serveurs, envisagez une centralisation sécurisée pour faciliter les recherches et conserver des traces même si un VPS devient indisponible. Limitez les accès, synchronisez l’heure des machines et surveillez les échecs d’expédition.

Enfin, associez toujours rotation et alertes disque. Des logs bien gérés restent disponibles pour diagnostiquer et sécuriser le VPS sans devenir eux-mêmes la cause d’une panne.