0Pricing
Linux Command Line & Bash Scripting Mastery · Leçon

Interroger journald avec journalctl dans les scripts

Filtrez les entrées du journal systemd par unité, priorité et période pour automatiser le triage des incidents.

Interroger journald avec journalctl dans les scripts est une leçon Linux Command Line & Bash Scripting Mastery gratuite sur CoddyKit. Ceci est la leçon 3 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 journald pour le diagnostic initial des incidents ?

Les systèmes Linux modernes exécutant systemd centralisent toutes les sorties de journaux dans le journal — un stockage structuré et binaire des journaux, géré par systemd-journald. Contrairement aux fichiers texte ordinaires de /var/log, chaque entrée du journal contient des métadonnées riches : nom de l’unité, niveau de priorité, PID, UID, horodatage, etc.

Dans les scripts automatisés de diagnostic initial des incidents, ces métadonnées vous permettent de :

  • filtrer les journaux d’un seul service sans enchaîner les commandes grep
  • restreindre les requêtes à des intervalles précis (les 15 dernières minutes, depuis un déploiement)
  • émettre uniquement les messages critiques ou d’erreur, en ignorant le bruit
  • alimenter directement les pipelines d’alerte avec une sortie structurée

L’outil qui expose toutes ces fonctionnalités est journalctl. Cette leçon vous apprend à le piloter par programme dans des scripts Bash.

Appel de base de journalctl

La forme la plus simple de journalctl affiche l’intégralité du journal. Dans les scripts, vous ne le souhaitez presque jamais : ajoutez toujours au moins un filtre. Voici les options les plus courantes que vous combinerez :

  • -u <unit> — filtrer par unité systemd (par exemple nginx.service)
  • -p <priority> — filtrer par priorité syslog (0=emerg … 7=debug)
  • --since / --until — fenêtre temporelle
  • -n <N> — N dernières lignes
  • --no-pager — désactiver la pagination interactive (essentiel dans les scripts)
  • -o <format> — format de sortie (short, json, cat, etc.)

Transmettez toujours --no-pager dans les scripts non interactifs afin que journalctl ne tente pas d’appeler less et ne reste bloqué.

#!/usr/bin/env bash
# Print the last 20 lines of the nginx service journal
journalctl --no-pager -u nginx.service -n 20

Filtrer par unité Systemd

L’option -u accepte tout nom d’unité valide. Vous pouvez la fournir plusieurs fois pour combiner des unités, ce qui est utile lorsqu’une seule application s’étend sur plusieurs services (par exemple une API et le service auxiliaire de sa base de données).

Les noms d’unité suivent le modèle <name>.service, <name>.socket, <name>.timer, etc. Les motifs génériques sont pris en charge : -u 'myapp*' correspond à myapp-api.service, myapp-worker.service, etc.

Dans un script de diagnostic initial, vous recevez généralement le nom de l’unité comme argument, ce qui rend le filtre dynamique.

#!/usr/bin/env bash
# Usage: ./unit_logs.sh nginx.service
UNIT="${1:?Usage: $0 <unit>}"

echo "=== Journal for ${UNIT} (last 50 lines) ==="
journalctl --no-pager -u "${UNIT}" -n 50

# Combine two related units
echo "=== Combined: api + worker ==="
journalctl --no-pager -u myapp-api.service -u myapp-worker.service -n 30

Niveaux de priorité et indicateur -p

L’indicateur -p correspond aux niveaux de priorité syslog standard :

  • 0 — emerg
  • 1 — alert
  • 2 — crit
  • 3 — err
  • 4 — warning
  • 5 — notice
  • 6 — info
  • 7 — debug

Vous pouvez spécifier un seul niveau (-p err) pour n’afficher que celui-ci, ou une plage (-p emerg..err) pour capturer tout ce qui va des urgences aux erreurs — le choix le plus courant pour les alertes automatisées.

Les alias nommés (err, warning, crit) sont acceptés au même titre que les valeurs numériques.

#!/usr/bin/env bash
# Extract only error-level and above entries for sshd
journalctl --no-pager \
  -u sshd.service \
  -p emerg..err \
  --since "1 hour ago"

# Exit non-zero if any errors were found (useful in CI health checks)
ERROR_COUNT=$(journalctl --no-pager -u sshd.service -p emerg..err \
  --since "1 hour ago" --output=cat | wc -l)

if [[ "${ERROR_COUNT}" -gt 0 ]]; then
  echo "[ALERT] ${ERROR_COUNT} error(s) detected in sshd" >&2
  exit 1
fi

Filtrage par intervalle temporel avec --since et --until

Les filtres temporels sont au cœur des requêtes portant sur une fenêtre d’incident. journalctl accepte des horodatages flexibles et lisibles par les humains :

  • Relatifs : "10 minutes ago", "2 hours ago", "yesterday"
  • Absolus : "2026-06-11 14:00:00"
  • Mots-clés spéciaux : today, yesterday, -1h (forme abrégée)

Dans les scripts de déploiement, il est courant de capturer l’horodatage juste avant un déploiement, puis d’interroger le journal à partir de ce moment afin de détecter les régressions introduites par la mise en production.

#!/usr/bin/env bash
# Record deploy start time, then check logs afterwards
DEPLOY_START=$(date +"%Y-%m-%d %H:%M:%S")

echo "Deploying at ${DEPLOY_START}..."
# ... your deploy steps here ...
sleep 2  # simulate deploy

echo "=== Journal since deploy start ==="
journalctl --no-pager \
  -u myapp.service \
  --since "${DEPLOY_START}" \
  -p emerg..warning

Sortie structurée au format JSON

Pour les chaînes de traitement lisibles par les machines, transmettez -o json (un objet JSON par ligne, NDJSON) ou -o json-pretty (formaté). Chaque objet contient tous les champs du journal :

  • MESSAGE — le texte du journal
  • PRIORITY — priorité numérique (0–7)
  • _SYSTEMD_UNIT — unité à l’origine de l’événement
  • __REALTIME_TIMESTAMP — microsecondes depuis l’époque Unix
  • _PID, _UID, _HOSTNAME — métadonnées du processus

Vous pouvez transmettre ce flux NDJSON à jq pour extraire, filtrer ou reformater les champs destinés aux systèmes d’alerte en aval, tels que PagerDuty, les webhooks Slack ou les collecteurs SIEM.

#!/usr/bin/env bash
# Extract error messages as a clean list for a Slack notification
MESSAGES=$(journalctl --no-pager \
  -u nginx.service \
  -p emerg..err \
  --since "30 minutes ago" \
  -o json \
  | jq -r '.MESSAGE' \
  | sort -u)

if [[ -n "${MESSAGES}" ]]; then
  echo "Errors detected:"
  echo "${MESSAGES}"
fi

Suivre le journal en temps réel

L’indicateur -f fait suivre le journal en direct par journalctl — comme le ferait tail -f sur un fichier de journal. Associé aux filtres d’unité et de priorité, il devient un moniteur ciblé en temps réel.

Dans les chaînes de traitement scriptées, l’approche la plus utile est l’interrogation fondée sur un curseur : enregistrez le curseur actuel du journal, puis transmettez --after-cursor=<cursor> à chaque interrogation pour ne lire que les nouvelles entrées depuis la dernière vérification. Cela évite de retraiter les anciennes lignes.

Récupérez le dernier curseur avec --show-cursor -n 0, puis analysez la ligne -- cursor: de la sortie.

#!/usr/bin/env bash
# Cursor-based polling: read only new journal entries each run
CURSOR_FILE="/tmp/triage_cursor"

if [[ -f "${CURSOR_FILE}" ]]; then
  CURSOR=$(cat "${CURSOR_FILE}")
  NEW_ENTRIES=$(journalctl --no-pager \
    -u myapp.service \
    -p emerg..err \
    --after-cursor="${CURSOR}" \
    -o json)
else
  # First run: look back 5 minutes
  NEW_ENTRIES=$(journalctl --no-pager \
    -u myapp.service \
    -p emerg..err \
    --since "5 minutes ago" \
    -o json)
fi

# Save updated cursor for next poll
journalctl --no-pager -n 0 --show-cursor 2>&1 \
  | grep '^-- cursor:' \
  | sed 's/-- cursor: //' \
  > "${CURSOR_FILE}"

echo "${NEW_ENTRIES}" | jq -r '.MESSAGE // empty'

Requêtes limitées au démarrage avec -b

L’indicateur -b limite une requête à une session de démarrage précise. C’est essentiel après une panne ou un redémarrage inattendu pour récupérer les journaux du démarrage précédent plutôt que ceux du démarrage actuel.

  • -b 0 — démarrage actuel (par défaut)
  • -b -1 — démarrage précédent
  • -b -2 — démarrage antérieur de deux sessions
  • --list-boots — afficher toutes les sessions de démarrage enregistrées avec leurs horodatages

Les scripts d’analyse post-mortem extraient souvent les journaux critiques du démarrage précédent (-b -1) afin de diagnostiquer la cause du plantage du système ou de l’échec d’un service au démarrage.

#!/usr/bin/env bash
# Post-mortem: collect critical logs from the previous boot
echo "=== Previous boot sessions ==="
journalctl --list-boots

echo ""
echo "=== Critical entries from previous boot ==="
journalctl --no-pager \
  -b -1 \
  -p emerg..crit \
  -o short-iso

Utiliser grep dans journalctl ou les correspondances natives

Vous pouvez transmettre un motif brut à grep après tous les indicateurs, mais journalctl prend également en charge les correspondances natives de champs avec la syntaxe FIELD=value. Les correspondances natives sont évaluées sur les métadonnées structurées — bien plus rapidement qu’un post-traitement du texte avec grep.

Correspondances courantes utiles :

  • _PID=1234 — journaux d’un processus précis
  • _COMM=python3 — journaux de tout processus nommé python3
  • SYSLOG_IDENTIFIER=myapp — journaux marqués avec un identifiant personnalisé

Plusieurs arguments FIELD=value sont combinés avec AND ; un + entre eux crée un OR. Utilisez -g <regex> pour effectuer une recherche plein texte avec grep lorsque les métadonnées structurées ne suffisent pas.

#!/usr/bin/env bash
# Native field match: errors from the postgres process only
journalctl --no-pager \
  _COMM=postgres \
  -p emerg..err \
  --since "1 hour ago"

# Full-text grep for a specific error string
journalctl --no-pager \
  -u postgresql.service \
  --since "1 hour ago" \
  -g "FATAL|PANIC" \
  --output=cat

Créer une fonction de triage réutilisable

Une fois que vous maîtrisez les indicateurs individuels, les composer dans une fonction Bash réutilisable permet de conserver des scripts de triage propres et cohérents. Une fonction bien conçue doit :

  • accepter l’unité, la plage de priorité et la fenêtre temporelle comme paramètres ;
  • utiliser par défaut des valeurs sûres et peu verbeuses lorsque des arguments sont omis ;
  • renvoyer un code de sortie différent de zéro lorsque des erreurs sont trouvées (pour s’intégrer aux chaînes de traitement d’intégration continue) ;
  • écrire les résultats à la fois sur la sortie standard et dans un fichier journal horodaté pour assurer la traçabilité.
#!/usr/bin/env bash
# triage.sh — reusable journal triage function

triage_unit() {
  local unit="${1:?unit required}"
  local priority="${2:-emerg..err}"
  local since="${3:-1 hour ago}"
  local logfile="/tmp/triage_${unit//[^a-zA-Z0-9]/_}_$(date +%s).log"

  echo "[$(date -Iseconds)] Triaging ${unit} | prio=${priority} | since='${since}'" | tee "${logfile}"

  journalctl --no-pager \
    -u "${unit}" \
    -p "${priority}" \
    --since "${since}" \
    -o short-iso \
    | tee -a "${logfile}"

  local count
  count=$(wc -l < "${logfile}")
  # Subtract 1 for the header line
  (( count-- ))

  if [[ "${count}" -gt 0 ]]; then
    echo "[ALERT] ${count} line(s) logged to ${logfile}" >&2
    return 1
  fi
  return 0
}

# Example: triage nginx errors in the last 30 minutes
triage_unit nginx.service "emerg..err" "30 minutes ago"

Script automatisé de triage d’incident

Le script complet suivant réunit tous les concepts dans un outil pratique de triage automatisé. Il lit une liste de services critiques, interroge le journal pour chacun d’eux sur une fenêtre configurable, regroupe les résultats et se termine avec un code d’échec si des erreurs ont été détectées — ce qui le rend adapté à une tâche cron ou à une étape de vérification de l’état d’une chaîne d’intégration continue.

#!/usr/bin/env bash
# incident_triage.sh — automated multi-service journal triage
set -euo pipefail

LOOKBACK="${1:-15 minutes ago}"
PRIORITY="emerg..err"
SERVICES=(nginx.service postgresql.service myapp-api.service myapp-worker.service)
REPORT="/tmp/incident_report_$(date +%Y%m%d_%H%M%S).txt"
FAILED=0

{
  echo "Incident Triage Report"
  echo "Generated : $(date -Iseconds)"
  echo "Lookback  : ${LOOKBACK}"
  echo "Priority  : ${PRIORITY}"
  echo "-----------------------------------"
} > "${REPORT}"

for svc in "${SERVICES[@]}"; do
  ENTRIES=$(journalctl --no-pager \
    -u "${svc}" \
    -p "${PRIORITY}" \
    --since "${LOOKBACK}" \
    --output=cat 2>/dev/null || true)

  COUNT=$(echo "${ENTRIES}" | grep -c . || true)

  if [[ "${COUNT}" -gt 0 ]]; then
    echo "[FAIL] ${svc}: ${COUNT} error(s)" | tee -a "${REPORT}"
    echo "${ENTRIES}" >> "${REPORT}"
    echo "-----------------------------------" >> "${REPORT}"
    FAILED=1
  else
    echo "[OK]   ${svc}"
  fi
done

echo ""
echo "Full report: ${REPORT}"
exit "${FAILED}"

Vérification des connaissances&nbsp;: filtrage par plage de priorité

Vous écrivez un script qui doit alerter les ingénieurs d’astreinte uniquement lorsqu’un service journalise des messages de gravité erreur ou supérieure (c’est-à-dire erreur, critique, alerte ou urgence). Quelle combinaison d’indicateurs journalctl capture exactement cette plage ?

Récapitulatif de la leçon&nbsp;: journalctl dans les scripts

Dans cette leçon, vous avez appris à interroger par programmation le journal systemd pour automatiser le triage des incidents :

  • Transmettez toujours --no-pager dans les scripts pour empêcher tout blocage interactif.
  • Le filtrage par unité (-u) limite les requêtes à un ou plusieurs services ; les motifs glob et plusieurs indicateurs -u sont pris en charge.
  • Le filtrage par priorité (-p emerg..err) ne capture que les niveaux de gravité qui vous intéressent — n’oubliez pas que les nombres les plus bas correspondent aux niveaux les plus graves.
  • Les fenêtres temporelles (--since / --until) limitent la sortie du journal à une fenêtre de déploiement ou à une période antérieure au moyen d’horodatages lisibles par les humains.
  • La limitation au démarrage (-b -1) permet aux scripts post-mortem de lire les journaux d’une session de panne précédente.
  • La sortie JSON (-o json) et jq permettent de créer des chaînes de traitement structurées alimentant des systèmes d’alerte ou des systèmes SIEM.
  • L’interrogation fondée sur un curseur avec --after-cursor évite de retraiter les anciennes entrées lors des exécutions répétées.
  • Les correspondances natives de champs (_COMM=, SYSLOG_IDENTIFIER=) sont plus rapides qu’une transmission à grep.

La combinaison de ces indicateurs dans une fonction Bash réutilisable vous fournit un outil de triage prêt pour la production, qui s’intègre proprement à cron, aux chaînes de traitement d’intégration continue et aux flux d’alerte d’astreinte.

Questions Fréquemment Posées

La leçon « Interroger journald avec journalctl dans les scripts » est-elle gratuite ?

Oui — le texte complet de « Interroger journald avec journalctl dans les scripts » 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 « Interroger journald avec journalctl dans les scripts » ?

Filtrez les entrées du journal systemd par unité, priorité et période pour automatiser le triage des incidents. 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 3 sur 4.

Combien de temps prend la leçon « Interroger journald avec journalctl dans les scripts » ?

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

  1. Analyser les journaux web et applicatifs à grande échelle
  2. Suivre les journaux en temps réel et diffuser des alertes
  3. Interroger journald avec journalctl dans les scripts
  4. Calculer des métriques et des histogrammes à partir de flux de journaux
← Retour à Linux Command Line & Bash Scripting Mastery