Parsing de logs : analyser les journaux de serveurs et d'applications, avec exemples

Les logs sont les journaux d'événements des serveurs, applications et services : chaque requête au site, chaque erreur, chaque action utilisateur y laisse une ligne. Le parsing de logs sert à l'analyse du trafic, à la recherche d'erreurs, aux investigations d'incidents de sécurité et au monitoring. Formellement, les logs sont des fichiers texte, et les techniques générales sont les mêmes ; mais ils ont assez de spécificités pour mériter un article à part dans notre panorama du parsing de documents.

En quoi les logs diffèrent du texte ordinaire

La particularité principale : au sein d'une même source, le format de ligne est strictement stable. Un serveur web écrit chaque ligne selon le même gabarit, ce qui permet d'analyser des millions de lignes avec une seule expression régulière. Mais il y a des complications. Les logs sont énormes — des gigaoctets par jour — impossible de les charger entièrement en mémoire, seule la lecture en flux convient. Ils subissent une rotation : les anciens fichiers sont renommés et compressés en .gz, et le parseur doit savoir lire les archives compressées. Enfin, on y rencontre des enregistrements multilignes — une trace d'erreur (stack trace) occupe des dizaines de lignes appartenant à un seul événement.

Formats standards des logs web

On analyse le plus souvent les access-logs de Nginx et Apache au format « combined ». Une ligne ressemble à ceci :

192.168.1.10 - - [01/Jun/2026:13:55:36 +0300] "GET /product/101 HTTP/1.1" 200 4523 "https://example.com/" "Mozilla/5.0 ..."

Dans l'ordre : adresse IP, date et heure, méthode et chemin de la requête, code de réponse, taille de la réponse, référent et User-Agent. Le format étant fixe, il se décompose commodément avec une seule expression régulière à groupes nommés.

Python

L'approche de base, et la plus souple : une expression régulière plus une lecture en flux. Les groupes nommés rendent le résultat lisible.

import re
import gzip

LOG_RE = re.compile(
    r'(?P<ip>\S+) \S+ \S+ \[(?P<time>[^\]]+)\] '
    r'"(?P<method>\S+) (?P<path>\S+) [^"]*" '
    r'(?P<status>\d{3}) (?P<size>\S+) '
    r'"(?P<referer>[^"]*)" "(?P<agent>[^"]*)"'
)

def open_log(path):
    # lecture transparente des fichiers ordinaires comme des compressés
    return gzip.open(path, "rt") if path.endswith(".gz") else open(path, "r")

with open_log("access.log") as f:
    for line in f:
        m = LOG_RE.match(line)
        if not m:
            continue
        row = m.groupdict()
        if row["status"] != "200":
            print(row["status"], row["method"], row["path"], row["ip"])

Quand il faut non seulement décomposer mais analyser — top des pages, distribution des codes de réponse, trafic par heure — le plus commode est de verser les lignes décomposées dans pandas et de les traiter comme un tableau.

import pandas as pd

records = [m.groupdict() for line in open_log("access.log")
           if (m := LOG_RE.match(line))]
df = pd.DataFrame(records)

# top 10 des pages les plus demandées
print(df["path"].value_counts().head(10))

# part des erreurs 5xx
errors = df[df["status"].str.startswith("5")]
print(len(errors) / len(df))

De là, le résultat s'exporte facilement en CSV ou Excel pour un rapport.

Ligne de commande : analyse rapide sans code

Pour une tâche ponctuelle, les utilitaires Unix sont souvent le plus rapide. awk découpe la ligne en champs et compte à la volée.

# top 10 des IP par nombre de requêtes
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head

# toutes les requêtes terminées en erreur 404
awk '$9 == 404 {print $7}' access.log | sort | uniq -c | sort -rn

# volume total de trafic servi (10e champ : la taille)
awk '{sum += $10} END {print sum/1024/1024 " MB"}' access.log

La combinaison grep + awk + sort + uniq répond à la plupart des questions ad hoc sur les logs sans rien écrire.

Analyseurs prêts à l'emploi

Si l'objectif est l'analyse générale du trafic web et non l'extraction de champs précis, inutile de réinventer un parseur. GoAccess lit les access-logs Nginx/Apache et construit un rapport interactif dans le terminal ou le navigateur, en temps réel. Pour les pipelines complexes à sources hétérogènes, on utilise une pile fondée sur Logstash et ses jeux de motifs grok — en somme, une bibliothèque d'expressions régulières nommées, prêtes à l'emploi pour les formats de logs courants.

Logs structurés (logs JSON)

Les applications modernes écrivent de plus en plus leurs logs non en lignes de texte mais en JSON — un objet par ligne (format JSON Lines). Un tel log s'analyse bien plus simplement et sûrement : pas de regex fragiles, chaque ligne se désérialise directement.

import json

with open("app.log") as f:
    for line in f:
        event = json.loads(line)
        if event.get("level") == "ERROR":
            print(event["timestamp"], event["message"])

Si vous pouvez influencer la façon dont les logs sont écrits, le passage à JSON Lines simplifie radicalement leur analyse ultérieure — pensez-y dès la conception du projet.

Les difficultés habituelles

Les problèmes les plus fréquents : les formats de date hétérogènes (les logs de systèmes différents utilisent des fuseaux et gabarits de dates différents, à ramener à une forme unique), les erreurs multilignes (une stack trace casse l'analyse ligne à ligne, il faut « recoller » les enregistrements en détectant le début de chaque nouvel événement) et le volume (analyser un log quotidien de plusieurs gigaoctets impose un traitement en flux et un filtrage à la volée, pas un chargement en mémoire).

S'il faut analyser régulièrement les logs de plusieurs serveurs, les consolider dans une analytique unique ou surveiller erreurs et activité suspecte, nous mettons en place la collecte et le parsing de logs selon vos formats, avec export des métriques vers le système de votre choix. Les techniques générales de traitement de texte libre sur lesquelles tout cela repose sont détaillées dans l'article sur le parsing de TXT.