IT Toolbox AI
Linux · Logs et diagnostic

Logs et diagnostic

Appliquez une méthode de diagnostic DevOps/SRE fondée sur les services, les logs et les ressources.

Leçon disponible
20 min

Objectifs

  • Comprendre où trouver les journaux système et applicatifs.
  • Filtrer le journal systemd avec journalctl.
  • Suivre et rechercher efficacement dans des fichiers de logs.
  • Appliquer une démarche de diagnostic avant toute correction.

Diagnostiquer avec les logs Linux

Les logs décrivent les événements produits par le système et les applications. Ils donnent le contexte temporel d’un symptôme : erreur, redémarrage, manque de ressource ou refus de connexion.

systemd-journald collecte le journal systemd consultable avec journalctl. Des fichiers persistent aussi souvent sous /var/log. Selon la distribution et le service syslog configuré, les messages généraux peuvent se trouver dans /var/log/syslog ou /var/log/messages.

Consulter le journal systemd

journalctl affiche les événements du journal. Les filtres par unité et par période réduisent le bruit. -xe ajoute des informations explicatives lorsqu’elles existent et positionne la vue vers les événements récents.

Consulter et cibler le journal
journalctl
journalctl -xe
journalctl -u nginx
journalctl --since "1 hour ago"

L’accès à certains événements peut être limité selon les groupes et privilèges de l’utilisateur.

Suivre et rechercher dans les fichiers

tail -f suit les nouvelles lignes en temps réel. grep recherche un motif ; -i ignore la casse, -n affiche les numéros de ligne et -E accepte des expressions régulières étendues.

Suivre un fichier syslog lorsqu’il existe
tail -f /var/log/syslog
Rechercher des erreurs avec différents filtres
grep "ERROR" app.log
grep -i "error" app.log
grep -n "timeout" app.log
grep -E "ERROR|WARN|FATAL" app.log

Sur certaines distributions de la famille RHEL, les messages généraux sont plutôt écrits dans /var/log/messages. Vérifiez les fichiers réellement configurés au lieu de supposer leur présence.

Une méthode de diagnostic en six étapes

Un bon diagnostic part du symptôme et rassemble des preuves avant la correction. Chaque étape réduit les hypothèses possibles.

  • 1. Identifier précisément le symptôme, son heure et son périmètre.
  • 2. Vérifier l’état du service concerné.
  • 3. Consulter les logs sur la même fenêtre temporelle.
  • 4. Vérifier CPU, mémoire et espace disque.
  • 5. Vérifier le réseau, les ports et les dépendances.
  • 6. Confirmer la cause avec une preuve avant d’appliquer une correction.

Exemple pratique : diagnostiquer nginx

Commencez par l’état et le journal récent. Vérifiez ensuite l’écoute réseau, l’espace disque et la mémoire. Corrélez les erreurs avec l’heure du symptôme au lieu de traiter chaque ligne ancienne comme une cause actuelle.

Collecter des indices sans modifier le service
systemctl status nginx
journalctl -u nginx --since "30 minutes ago"
ss -tulpn
df -h
free -h

Bonnes pratiques

Conservez l’ordre chronologique, le fuseau horaire et le contexte autour d’une erreur. Masquez les secrets avant de partager des logs et ne redémarrez pas un service avant d’avoir collecté les éléments volatils utiles.

  • Filtrer par service et période avant de rechercher un motif.
  • Lire quelques lignes avant et après l’erreur principale.
  • Distinguer symptôme, conséquence et cause racine.

Mini résumé

  • journalctl interroge le journal systemd et accepte des filtres par unité et période.
  • Les fichiers sous /var/log varient selon la distribution et la configuration.
  • tail -f suit un flux ; grep filtre les événements pertinents.
  • Un diagnostic fiable collecte des preuves et confirme la cause avant correction.

Analyser un extrait avec Log Analyzer

Collez un extrait anonymisé dans l’outil local pour repérer rapidement niveaux, motifs fréquents et lignes importantes.

Ouvrir Log Analyzer

Mini quiz

Trois questions pour vérifier les notions essentielles de la leçon.

1. Pourquoi filtrer les logs sur la période du symptôme ?
2. Pourquoi /var/log/syslog peut-il être absent sur une machine RHEL ?
3. Après une erreur nginx, quelle démarche favorise l’identification de la cause racine ?