journalctl pour debug systemd : méthode rapide en production

Réponse rapide

journalctl est l’outil officiel systemd pour lire les journaux. Pour un incident, cible le service puis restreins la période.

systemctl status nginx --no-pager
journalctl -u nginx -n 200 --no-pager
journalctl -u nginx --since "1 hour ago"

Contexte

Quand un service tombe, le réflexe “restart” peut masquer la cause. L’approche fiable : observer d’abord les logs, corriger ensuite.

Méthode de diagnostic fiable

1) Vérifier l’état systemd

systemctl status myapp --no-pager

2) Lire les derniers événements

journalctl -u myapp -n 200 --no-pager

3) Cibler la fenêtre d’incident

journalctl -u myapp --since "2026-02-11 20:00" --until "2026-02-11 20:30"

4) Corréler avec le réseau

ss -ltnp | grep 443

Exemples utiles

Afficher seulement les erreurs

journalctl -p err -u myapp --since "30 min ago"

Suivre en direct

journalctl -u myapp -f

Bonnes pratiques

• conserver un mini runbook par service critique,
• noter la commande exacte utilisée dans le ticket incident,
• valider l’état après correctif (pas seulement après restart).

FAQ

journalctl remplace-t-il totalement /var/log ?

Pour les services systemd, c’est souvent la source principale. Certains logiciels conservent aussi des logs applicatifs dédiés.

Comment limiter la sortie ?

Avec -n et --since/--until.

Glossaire rapide

• Regex : expression régulière pour décrire un motif de recherche texte.
• MTTR : temps moyen de rétablissement après incident.
• CI/CD : intégration continue / déploiement continu.
• Idempotence : relancer une tâche donne le même état final sans effet secondaire indésirable.

Sources officielles

• man grep
• GNU grep manual
• journalctl (systemd)
• man ss
• Ansible Vault docs
• Ansible Playbooks
• Securing Debian Manual

Conclusion

Une lecture structurée de journalctl réduit le temps de résolution et évite les actions “à l’aveugle”.