Léo Le Mounier -- Langlois

"Error: No space left on device". Si vous voyez ce message, c'est souvent trop tard : vos logs ont saturé le disque dur. Savoir lire les journaux système est vital pour le débogage, mais savoir les gérer automatiquement avec Logrotate est obligatoire pour la survie de vos serveurs.

1. Où se cachent les infos ? (La hiérarchie)

Sur Debian/Ubuntu, tout se passe dans /var/log. Voici les fichiers que vous devez connaître par cœur :

/var/log/syslog : Le journal général. Tout ce qui n'a pas de fichier dédié finit ici.
/var/log/auth.log : Sécurité. Connexions SSH (réussies ou échouées), sudo, etc.
/var/log/dmesg : Logs du noyau (Kernel) et détection matériel au démarrage.
/var/log/nginx/access.log : (Si serveur web) Qui a visité quelle page ?
/var/log/nginx/error.log : Pourquoi mon site a planté (Erreur 500) ?

2. Les outils d'analyse (Le couteau suisse)

Oubliez cat (qui va afficher 10 millions de lignes et bloquer votre terminal). Voici comment travaille un pro :

A. Le temps réel (tail)

Pour voir ce qu'il se passe maintenant (ex: quand vous rechargez une page web) :

tail -f /var/log/nginx/error.log

Astuce : -f signifie "Follow". Ajoutez -n 100 pour voir les 100 dernières lignes avant de suivre.

B. La recherche (grep)

Pour trouver une erreur spécifique ou une IP suspecte :

grep "error" /var/log/syslog
grep "192.168.1.55" /var/log/auth.log

C. Systemd (journalctl)

Les distributions modernes utilisent Systemd, qui stocke les logs en binaire (plus rapide). On les lit avec journalctl :

# Voir les logs du service SSH uniquement
journalctl -u ssh

# Voir les logs en temps réel (comme tail -f)
journalctl -f

# Voir les erreurs graves (Priority: Error)
journalctl -p 3 -xb

3. La solution : Logrotate

Un fichier log grossit indéfiniment. Logrotate est un service qui, chaque nuit :

Renomme le fichier actuel (ex: syslog devient syslog.1).
Compresse les très vieux fichiers (syslog.2.gz).
Supprime les fichiers trop anciens (après X jours).
Crée un nouveau fichier vide pour que le service continue d'écrire.

Configurer une rotation personnalisée

Imaginons que vous ayez une application maison qui écrit dans /var/log/mon-app.log. Créons une règle pour elle.

sudo nano /etc/logrotate.d/mon-app

Collez cette configuration type :

/var/log/mon-app.log {
    daily           # Rotation tous les jours
    rotate 7        # Garder 7 fichiers (donc 1 semaine d'historique)
    compress        # Compresser les archives (.gz) pour gagner de la place
    delaycompress   # Ne pas compresser le fichier d'hier (utile si l'app écrit encore dedans)
    missingok       # Ne pas planter si le fichier log n'existe pas
    notifempty      # Ne pas tourner si le fichier est vide
    create 0640 www-data adm  # Permissions du nouveau fichier créé
    
    # Script à lancer APRÈS la rotation (ex: recharger Nginx)
    postrotate
        systemctl reload mon-app > /dev/null 2>&1 || true
    endscript
}

4. Tester sa configuration (Dry Run)

Ne jamais attendre minuit pour voir si ça marche. Forcez le test avec le mode debug :

logrotate -d /etc/logrotate.d/mon-app

Vous verrez exactement ce que Logrotate ferait (sans le faire réellement). Si vous voulez forcer la rotation immédiatement :

logrotate -f /etc/logrotate.d/mon-app

Conclusion

Une bonne politique de logs, c'est l'assurance de pouvoir diagnostiquer un piratage remontant à 2 semaines, sans pour autant sacrifier 50% de son espace disque. Vérifiez toujours que vos services critiques (Base de données, Web) ont bien un fichier de conf dans /etc/logrotate.d/.