Linux Command Line & Bash Scripting Mastery · Leçon

Suivre les journaux en temps réel et diffuser des alertes

Suivez et filtrez les flux de journaux en direct pour déclencher des alertes dès l’apparition de motifs d’erreur.

Suivre les journaux en temps réel et diffuser des alertes est une leçon Linux Command Line & Bash Scripting Mastery gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Linux Command Line & Bash Scripting Mastery, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Linux Command Line & Bash Scripting Mastery comprend 4 leçons au total.

Pourquoi le suivi des journaux en temps réel est important

Dans les systèmes de production, les fichiers journaux grossissent continuellement. Attendre qu’un problème soit signalé avant d’examiner les journaux signifie que l’interruption de service vous a déjà coûté cher. Le suivi des journaux en temps réel vous permet d’observer les événements au moment même où ils sont écrits et de réagir immédiatement aux défaillances, aux événements de sécurité et aux dégradations des performances.

Les serveurs web écrivent une ligne par requête : les erreurs apparaissent instantanément
Les démons applicatifs consignent les traces de pile au moment même où une exception se produit
Les systèmes d’authentification enregistrent les tentatives de connexion échouées en temps réel

L’outil Unix fondamental pour cela est tail -f, associé à des utilitaires de filtrage et d’alerte pour transformer les flux bruts de journaux en signaux exploitables.

tail -f : suivre un journal en direct

tail -f (suivre) garde le fichier ouvert et affiche les nouvelles lignes au fur et à mesure de leur ajout. C’est l’outil de journalisation en temps réel le plus simple et le plus largement disponible.

Exemples d’utilisation courants :

tail -f /var/log/syslog — suivre le journal système
tail -n 50 -f app.log — afficher les 50 dernières lignes, puis continuer le suivi
tail -f /var/log/nginx/access.log — suivre en direct les requêtes nginx

Appuyez sur Ctrl+C pour arrêter. Le processus reste attaché jusqu’à ce que vous l’annuliez ou que le terminal se ferme.

#!/usr/bin/env bash
# Simulate a live log and follow it
LOGFILE='/tmp/demo_app.log'

# Write a header
echo '[INFO] Application started' >> "$LOGFILE"

# In a real scenario you would run:
# tail -f "$LOGFILE"
# Below we demonstrate tail showing the last 3 lines then exit
tail -n 3 "$LOGFILE"

tail -F : résister à la rotation des journaux

De nombreux systèmes effectuent une rotation des fichiers journaux à minuit ou lorsqu’ils atteignent une certaine taille. Dans ce cas, le fichier d’origine est renommé (par exemple app.log.1) et un nouveau fichier app.log est créé. Avec tail -f, vous continuez silencieusement à lire l’ancien fichier renommé et vous manquez toutes les nouvelles sorties.

tail -F (F majuscule) résout ce problème en surveillant le nom du fichier, et non le descripteur de fichier. Lorsque le fichier disparaît puis réapparaît, tail -F le rouvre automatiquement et reprend le suivi.

Dans les scripts de production, préférez toujours tail -F à tail -f
Fonctionne avec logrotate, newsyslog et les pilotes de journaux Docker qui effectuent une rotation des fichiers

# Follow nginx access log, surviving log rotation
tail -F /var/log/nginx/access.log

# Follow multiple files simultaneously
tail -F /var/log/nginx/access.log /var/log/nginx/error.log

Filtrer le flux avec grep

Suivre directement un journal très actif est accablant : un serveur web en activité peut écrire des centaines de lignes par seconde. Envoyez la sortie de tail -F vers grep pour isoler uniquement les motifs qui vous intéressent.

Options importantes de grep pour les flux :

--line-buffered — vider immédiatement chaque ligne correspondante au lieu de la mettre en mémoire tampon ; cette option est obligatoire dans les pipelines, sinon la sortie sera retardée ou perdue
-i — effectuer une recherche insensible à la casse
-E — utiliser les expressions régulières étendues pour l’alternance (error|warn|crit)
-v — inverser la recherche (exclure les lignes)

# Show only ERROR and WARN lines from a live application log
tail -F /var/log/myapp/app.log | grep --line-buffered -Ei 'error|warn|critical'

# Follow nginx and exclude health-check requests
tail -F /var/log/nginx/access.log | grep --line-buffered -v '/health'

Ajouter des horodatages et du contexte avec awk

Les lignes de journal manquent parfois du contexte utile au diagnostic initial. Vous pouvez enrichir le flux en temps réel avec awk — en ajoutant un horodatage local, en extrayant des champs ou en reformatant la sortie pour la rendre plus lisible.

awk fonctionne également en mode flux (avec mise en mémoire tampon ligne par ligne) lorsqu’il est utilisé dans un pipeline, ce qui permet de l’employer sans risque dans des pipelines en direct, sans option supplémentaire.

# Prepend a reception timestamp to every ERROR line
tail -F /var/log/myapp/app.log | \
  grep --line-buffered -i 'error' | \
  awk '{ print strftime("[%Y-%m-%d %H:%M:%S]"), $0; fflush() }'

# Extract HTTP status code (field 9) and URL (field 7) from nginx combined log
tail -F /var/log/nginx/access.log | \
  awk '{ print $9, $7; fflush() }' | \
  grep --line-buffered '^5'

Envoyer des alertes avec les webhooks Slack

Le filtrage ne représente que la moitié du travail : une fois un motif d’erreur détecté, vous devez prévenir quelqu’un. Un webhook entrant Slack vous permet d’envoyer un message à un canal avec un seul appel à curl, sans SDK Slack ni identifiants autres que l’URL du webhook.

Le principe est le suivant : filtrer le flux et envoyer une requête HTTP POST pour chaque ligne correspondante.

#!/usr/bin/env bash
# Real-time alert: send every ERROR line to a Slack channel
LOGFILE='/var/log/myapp/app.log'
WEBHOOK_URL='https://hooks.slack.com/services/T000/B000/XXXX'

tail -F "$LOGFILE" | grep --line-buffered -i 'error' | while IFS= read -r line; do
  payload=$(printf '{"text":"*[ERROR ALERT]*\n%s"}' "$line")
  curl -s -o /dev/null -X POST -H 'Content-Type: application/json' \
    -d "$payload" "$WEBHOOK_URL"
done

Limiter le débit des alertes pour éviter le bruit

Une tempête de journaux peut générer des milliers de lignes d’erreur par minute. Envoyer un message Slack par ligne inondera le canal et provoquera une fatigue liée aux alertes. Vous devez limiter le débit : déclencher l’alerte, puis supprimer les notifications suivantes pendant une période de refroidissement.

Pour cela, utilisez un simple fichier d’horodatage : enregistrez l’heure d’envoi de la dernière alerte et ne déclenchez rien si la période de refroidissement n’est pas écoulée.

#!/usr/bin/env bash
# Alert on ERROR lines but no more than once every 60 seconds
LOGFILE='/var/log/myapp/app.log'
WEBHOOK_URL='https://hooks.slack.com/services/T000/B000/XXXX'
COOLDOWN=60
LAST_ALERT_FILE='/tmp/last_alert_ts'

tail -F "$LOGFILE" | grep --line-buffered -i 'error' | while IFS= read -r line; do
  now=$(date +%s)
  last=0
  [ -f "$LAST_ALERT_FILE" ] && last=$(cat "$LAST_ALERT_FILE")

  if (( now - last >= COOLDOWN )); then
    echo "$now" > "$LAST_ALERT_FILE"
    payload=$(printf '{"text":"*[ERROR ALERT]*\n%s"}' "$line")
    curl -s -o /dev/null -X POST -H 'Content-Type: application/json' \
      -d "$payload" "$WEBHOOK_URL"
    echo "[$(date)] Alert sent: $line"
  else
    echo "[$(date)] Suppressed (cooldown): $line"
  fi
done

Compter les rafales d’erreurs avec une fenêtre glissante

Une seule ligne d’erreur n’est parfois pas significative, mais 20 erreurs en 30 secondes constituent un problème sérieux. Un compteur à fenêtre glissante vous permet de déclencher des alertes uniquement lorsqu’un seuil de taux d’erreur est dépassé, ce qui réduit les faux positifs.

Cette technique enregistre l’horodatage epoch de chaque événement correspondant dans un fichier temporaire, puis compte ceux qui se trouvent dans la fenêtre avant de décider s’il faut envoyer une alerte.

#!/usr/bin/env bash
# Alert when more than 10 errors occur within any 60-second window
LOGFILE='/var/log/myapp/app.log'
WINDOW=60
THRESHOLD=10
TS_FILE='/tmp/error_timestamps'
WEBHOOK_URL='https://hooks.slack.com/services/T000/B000/XXXX'

tail -F "$LOGFILE" | grep --line-buffered -i 'error' | while IFS= read -r line; do
  now=$(date +%s)
  echo "$now" >> "$TS_FILE"

  # Keep only timestamps within the window
  cutoff=$(( now - WINDOW ))
  tmp=$(mktemp)
  awk -v c="$cutoff" '$1 > c' "$TS_FILE" > "$tmp" && mv "$tmp" "$TS_FILE"

  count=$(wc -l < "$TS_FILE")
  if (( count > THRESHOLD )); then
    msg="*[BURST ALERT]* ${count} errors in ${WINDOW}s — last: ${line}"
    curl -s -o /dev/null -X POST -H 'Content-Type: application/json' \
      -d "{\"text\":\"$msg\"}" "$WEBHOOK_URL"
    # Clear to avoid re-alerting until next burst
    > "$TS_FILE"
  fi
done

journalctl -f : suivre les journaux systemd

Sur les systèmes Linux modernes (RHEL, Ubuntu 20.04+, Debian 10+), les services écrivent dans le journal systemd plutôt que dans des fichiers texte ordinaires. journalctl -f est l’équivalent de tail -F pour le journal.

Options utiles :

-u myapp.service — suivre uniquement une unité donnée
-p err — filtrer par priorité (emerg, alert, crit, err, warning, notice, info, debug)
--since '5 min ago' — commencer à partir d’une durée relative
-o json — produire un JSON structuré pour l’analyse par une machine

# Follow only error-and-above entries for nginx
journalctl -f -u nginx.service -p err

# Stream journal as JSON and extract MESSAGE field with jq
journalctl -f -u myapp.service -o json | \
  jq --unbuffered -r 'select(.PRIORITY <= "3") | .MESSAGE'

multitail et surveillance multsource codée en couleurs

Lorsque vous devez surveiller plusieurs sources de journaux simultanément, multitail divise le terminal en volets — chacun suivant un fichier ou une commande différente — avec un codage couleur facultatif selon le motif.

Si multitail n’est pas installé, une solution légère entièrement en BASH consiste à préfixer chaque flux avec le nom de sa source et à les fusionner dans une seule vue.

# multitail: watch nginx access + error + app log in split panes
# (requires: apt install multitail  or  brew install multitail)
multitail /var/log/nginx/access.log /var/log/nginx/error.log /var/log/myapp/app.log

# Pure-Bash alternative — merge three streams with labeled prefixes
(
  tail -F /var/log/nginx/access.log | sed --unbuffered 's/^/[nginx-access] /' &
  tail -F /var/log/nginx/error.log  | sed --unbuffered 's/^/[nginx-error]  /' &
  tail -F /var/log/myapp/app.log    | sed --unbuffered 's/^/[myapp]        /' &
  wait
)

Créer un démon d’alerte autonome

En réunissant tous les éléments de cette leçon, un démon d’alerte prêt pour la production devrait :

suivre le fichier journal de manière robuste avec tail -F
filtrer les motifs critiques avec grep mis en mémoire tampon
limiter le débit des notifications pour éviter la fatigue liée aux alertes
consigner sa propre activité afin que vous puissiez vérifier ce qui a été envoyé
s’exécuter comme processus en arrière-plan géré par systemd ou un superviseur

Le script ci-dessous est un démon minimal mais complet que vous pouvez déposer dans /usr/local/bin/ et gérer avec systemd.

#!/usr/bin/env bash
# log_alert_daemon.sh — tail a log and fire Slack alerts with cooldown
set -euo pipefail

LOGFILE=${1:-'/var/log/myapp/app.log'}
PATTERN=${2:-'error|critical|fatal'}
WEBHOOK_URL=${SLACK_WEBHOOK_URL:?'Set SLACK_WEBHOOK_URL env var'}
COOLDOWN=${ALERT_COOLDOWN:-120}
DAEMON_LOG='/var/log/log_alert_daemon.log'
LAST_SENT_FILE='/tmp/log_alert_last_sent'

log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$DAEMON_LOG"; }

log "Starting alert daemon: watching $LOGFILE for pattern: $PATTERN"

tail -F "$LOGFILE" | grep --line-buffered -Ei "$PATTERN" | while IFS= read -r line; do
  now=$(date +%s)
  last=0
  [ -f "$LAST_SENT_FILE" ] && last=$(cat "$LAST_SENT_FILE")

  if (( now - last >= COOLDOWN )); then
    echo "$now" > "$LAST_SENT_FILE"
    msg=$(printf '{"text":"*[ALERT]* %s\n%s"}' "$(hostname)" "$line")
    if curl -s -o /dev/null -w '%{http_code}' -X POST \
         -H 'Content-Type: application/json' -d "$msg" "$WEBHOOK_URL" | grep -q '^200$'; then
      log "Alert sent: $line"
    else
      log "Alert FAILED to send: $line"
    fi
  else
    log "Suppressed (cooldown ${COOLDOWN}s): $line"
  fi
done

Vérification des connaissances : pipelines de journaux en flux

Vérifiez votre compréhension du suivi des journaux en temps réel et des alertes en flux.

Un pipeline Bash suit un fichier journal et envoie une alerte Slack pour chaque ligne correspondante. Pendant une tempête de journaux, 3 000 lignes d’erreur sont écrites en 10 secondes. Quelle modification unique empêche le mieux le script d’inonder le canal Slack de 3 000 messages ?

Récapitulatif de la leçon : suivi des journaux en temps réel et alertes en flux

Dans cette leçon, vous avez construit à partir de principes fondamentaux un pipeline complet d’observabilité des journaux en temps réel :

tail -F suit un fichier journal par son nom et résiste à la rotation des journaux — préférez-le toujours à tail -f en production
grep --line-buffered filtre le flux en direct sans ajouter de latence : ajoutez toujours cette option aux commandes grep utilisées dans un pipeline
awk avec fflush() enrichit chaque ligne avec des horodatages ou des champs extraits, de manière compatible avec le traitement en flux
Webhooks Slack via curl transmettent les alertes avec une seule requête HTTP POST — aucun SDK requis
Fichiers de refroidissement évitent la fatigue liée aux alertes pendant les tempêtes de journaux en imposant un intervalle minimal entre les notifications
Compteurs à fenêtre glissante détectent les rafales d’erreurs (alertes fondées sur le taux) plutôt que de réagir à chaque ligne individuelle
journalctl -f est l’équivalent natif de tail -F pour systemd, avec filtrage intégré par priorité et sortie JSON
Un script de démon d’alerte autonome combine tous ces motifs et peut être géré par systemd pour assurer la fiabilité en production

Ces primitives se combinent pour former la base de tout pipeline d’observabilité personnalisé — aucun agent tiers requis.

Questions Fréquemment Posées

La leçon « Suivre les journaux en temps réel et diffuser des alertes » est-elle gratuite ?

Oui — le texte complet de « Suivre les journaux en temps réel et diffuser des alertes » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Linux Command Line & Bash Scripting Mastery, passe à CoddyKit PRO. Le cours Linux Command Line & Bash Scripting Mastery comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Suivre les journaux en temps réel et diffuser des alertes » ?

Suivez et filtrez les flux de journaux en direct pour déclencher des alertes dès l’apparition de motifs d’erreur. Tu pratiques Linux Command Line & Bash Scripting Mastery avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Linux Command Line & Bash Scripting Mastery ?

Aucune expérience préalable n'est requise. Linux Command Line & Bash Scripting Mastery sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.

Combien de temps prend la leçon « Suivre les journaux en temps réel et diffuser des alertes » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Linux Command Line & Bash Scripting Mastery ?

Oui. Chaque leçon Linux Command Line & Bash Scripting Mastery inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

Analyser les journaux web et applicatifs à grande échelle
Suivre les journaux en temps réel et diffuser des alertes
Interroger journald avec journalctl dans les scripts
Calculer des métriques et des histogrammes à partir de flux de journaux

← Retour à Linux Command Line & Bash Scripting Mastery