infra / linux-bash
Logs (journalctl, rsyslog)
Explication
Quand un service comme nginx plante en pleine nuit, tu n'es pas là pour observer en direct ce qui se passe. Les logs sont la seule trace disponible après coup : sans eux, diagnostiquer un incident revient à deviner plutôt qu'à comprendre.
Ce que vous allez apprendre
- Consulter les logs d'un service précis avec
journalctl -uet les filtrer par date ou gravité - Comprendre pourquoi le journal systemd peut disparaître au redémarrage et comment le rendre persistant
- Retrouver les logs texte classiques dans
/var/log/(syslog, auth.log) avectail -fetgrep - Configurer
logrotatepour empêcher un fichier de log de saturer le disque - Envoyer un message de log custom depuis un script bash avec
logger
Dans quel contexte ?
Un administrateur système reçoit une alerte à 4h du matin : le service mon-app a redémarré plusieurs fois dans la nuit. Il doit remonter le fil des événements précis à l'heure de l'incident, croiser les logs applicatifs (journalctl -u mon-app --since "03:00") avec les logs d'authentification (/var/log/auth.log) pour vérifier qu'il ne s'agit pas d'une intrusion, et s'assurer que ces traces ne disparaîtront pas au prochain redémarrage du serveur.
Ensuite, il faut savoir qu'il existe deux systèmes de logs qui coexistent
| Système | Format | Exemple de consultation |
|---|---|---|
journalctl (systemd) | Journal binaire structuré | journalctl -u nginx -f |
| rsyslog | Fichiers texte classiques | tail -f /var/log/syslog |
journalctl interroge le journal binaire de systemd, filtrable par service, par date, par gravité. rsyslog, plus ancien, écrit dans de simples fichiers texte comme /var/log/syslog ou /var/log/auth.log, encore utilisés par de nombreuses applications.
Un exemple concret : journalctl -u nginx --since "1 hour ago" affiche uniquement les logs de nginx de la dernière heure. Ajoute -f pour les suivre en temps réel, comme tail -f, ou -p err pour ne garder que les erreurs et plus grave.
Piège fréquent
Par défaut, le journal systemd est souvent volatile : il peut être perdu à chaque redémarrage de la machine, un choix fait pour économiser l'espace disque. Sur un serveur de production, c'est gênant si tu dois enquêter sur un incident survenu juste avant un reboot — crée /var/log/journal et relance systemd-journald pour le rendre persistant.
Maintenant, un problème différent : les fichiers de log qui grossissent
Un fichier comme /var/log/mon-app/app.log jamais nettoyé finit par saturer le disque et devenir illisible. logrotate automatise sa rotation : il le renomme, le compresse, et supprime les versions trop anciennes (rotate 14 garde 14 jours d'historique).
Bonne pratique
Chercher une erreur uniquement dans journalctl alors qu'une application écrit ses propres logs dans un fichier texte à part fait perdre un temps précieux : prends l'habitude de vérifier systématiquement les deux mondes (journal systemd ET fichiers dans /var/log/) avant de conclure qu'un incident n'a laissé aucune trace.
Maintenant que tu sais consulter les traces d'un système, la prochaine leçon aborde comment le sécuriser activement.
Commandes & code
Logs : journalctl et rsyslog
# journalctl : logs centralisés par systemd (journal binaire)
journalctl # tous les logs, du plus ancien au plus récent
journalctl -e # va directement à la fin
journalctl -f # suit en temps réel (comme tail -f)
journalctl -u nginx # logs d'un service précis
journalctl -u nginx -f # logs d'un service en temps réel
journalctl -u nginx --since "1 hour ago" # fenêtre temporelle relative
journalctl --since "2026-09-01" --until "2026-09-02" # fenêtre temporelle absolue
journalctl -p err # uniquement niveau erreur et plus grave
journalctl -p warning..err # plage de priorités
journalctl -k # logs du noyau uniquement (kernel ring buffer)
journalctl -b # logs depuis le dernier boot
journalctl -b -1 # logs du boot précédent
journalctl --disk-usage # espace disque utilisé par le journal
journalctl -o json-pretty -u nginx -n 5 # sortie JSON, utile pour parser en script
# Rendre le journal persistant (par défaut souvent volatile, perdu au reboot)
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
# Limiter la taille du journal (évite de saturer le disque)
# /etc/systemd/journald.conf
# SystemMaxUse=500M
# --- rsyslog : logs texte classiques dans /var/log ---
tail -f /var/log/syslog # (Debian/Ubuntu)
tail -f /var/log/messages # (RHEL/CentOS)
tail -f /var/log/auth.log # tentatives de connexion, sudo, SSH
grep "Failed password" /var/log/auth.log | tail -20 # tentatives SSH échouées
# Rotation des logs : logrotate (empêche les fichiers de grossir indéfiniment)
cat /etc/logrotate.d/mon-app
# /var/log/mon-app/*.log {
# daily
# rotate 14
# compress
# delaycompress
# missingok
# notifempty
# copytruncate
# }
sudo logrotate --debug /etc/logrotate.d/mon-app # simulation sans rien exécuter
sudo logrotate -f /etc/logrotate.d/mon-app # force une rotation immédiate
# Envoyer un log applicatif custom vers le système (utile depuis un script bash)
logger -t mon-script "Backup terminé avec succès"
logger -p local0.err -t mon-script "Erreur critique pendant le backup"Résumé
journalctl -u <service> -f --since "..."couvre 90% des besoins de debug au quotidien.- Le journal systemd est volatile par défaut : le rendre persistant si tu veux garder l'historique entre reboots.
logrotateévite qu'un fichier de log grossisse indéfiniment et sature le disque en production.
Exercices pratiques
Mission : remonter le fil d'une nuit d'incidents
Objectif : Croiser journal systemd et logs texte classiques pour diagnostiquer des redémarrages nocturnes suspects.
Contexte
Un administrateur reçoit une alerte : le service mon-app a redémarré plusieurs fois cette nuit. Le serveur vient aussi d'être rebooté il y a 10 minutes pour tester un correctif. Tu dois retrouver ce qui s'est passé et t'assurer que ce genre de trace ne disparaîtra plus à l'avenir.