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

Conclusion

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

Tags: , ,

Laisser un commentaire