Parser Logs

Qu’est-ce que l’analyse de logs ?

L’analyse de logs est le processus d’extraction de donnees structurees a partir de fichiers de logs — transformer des lignes de texte brut en champs nommes (horodatage, adresse IP, code de statut, message) qui peuvent etre recherches, filtres et analyses.

Les applications generent des logs pour enregistrer les evenements : requetes HTTP, erreurs, tentatives d’authentification, requetes de base de donnees, changements d’etat du systeme. Ces logs sont essentiels pour le debogage, la surveillance, l’audit de securite et l’analyse de performance. Mais les fichiers de logs bruts ne sont que des lignes de texte — pour les rendre utiles, il faut les analyser en donnees structurees.

Le defi est que les formats de logs varient enormement. Apache, Nginx, syslog et les formats specifiques aux applications utilisent chacun des mises en page, des delimiteurs et des formats de date differents. Un analyseur de logs doit comprendre le format attendu et extraire chaque champ par sa position et son modele.

Formats de logs courants

Format Apache/Nginx Common Log (CLF)

127.0.0.1 - frank [10/Oct/2024:13:55:36 -0700] "GET /page.html HTTP/1.1" 200 2326

Champ	Valeur	Description
Hote distant	127.0.0.1	Adresse IP du client
Identite	-	Identite RFC 1413 (rarement utilisee)
Utilisateur	frank	Nom d’utilisateur authentifie (ou -)
Horodatage	[10/Oct/2024:13:55:36 -0700]	Heure de la requete avec fuseau horaire
Requete	"GET /page.html HTTP/1.1"	Methode, chemin et protocole
Statut	200	Code de statut de la reponse HTTP
Taille	2326	Taille du corps de la reponse en octets

Le format Combined Log ajoute deux champs supplementaires : l’URL du referrer et la chaine d’agent utilisateur.

Syslog (RFC 5424)

<34>1 2024-10-10T13:55:36.123Z server1 myapp 1234 - - Application started

Syslog est le protocole de journalisation standard pour les systemes Unix/Linux. Il inclut une valeur de priorite (categorie + severite), la version, un horodatage ISO 8601, le nom d’hote, le nom de l’application, l’identifiant du processus, l’identifiant du message, les donnees structurees et le corps du message.

Logs structures JSON

{"timestamp":"2024-10-10T13:55:36.123Z","level":"INFO","service":"api","message":"Request processed","duration_ms":42,"status":200}

Les logs JSON sont le standard moderne. Chaque champ est explicitement nomme, rendant l’analyse triviale — il suffit d’appeler JSON.parse() sur chaque ligne. Pas de regex necessaire, pas d’ambiguite positionnelle, et de nouveaux champs peuvent etre ajoutes sans casser les analyseurs existants.

Regex vs journalisation structuree

Les formats de logs traditionnels (Apache, syslog) necessitent une analyse basee sur les regex. Vous ecrivez un modele qui correspond au format attendu et capture chaque champ dans un groupe nomme. Cela fonctionne bien pour les formats connus mais echoue quand les logs contiennent des caracteres inattendus, des messages multi-lignes ou des changements de format.

La journalisation structuree (JSON, logfmt) elimine entierement les regex. Chaque entree de log est une structure de donnees auto-descriptive. Cette approche est :

• Plus facile a analyser — Les analyseurs JSON/logfmt standard gerent tout
• Plus robuste — Pas de maintenance de regex quand les formats changent
• Meilleure pour la recherche — Les agregateurs de logs peuvent indexer les champs individuels
• Plus extensible — Ajoutez des champs sans casser les consommateurs existants

Le compromis est la lisibilite. Une ligne de log JSON est plus difficile a parcourir a l’oeil nu qu’une ligne de texte bien formatee. De nombreuses equipes utilisent la journalisation JSON en production (pour la consommation machine) et un formatage lisible par l’homme en developpement.

Niveaux de log

La plupart des frameworks de journalisation utilisent une hierarchie de niveaux de severite :

Niveau	Severite	Cas d’usage
TRACE	La plus basse	Debogage fin (iterations de boucle, valeurs de variables)
DEBUG	Basse	Informations diagnostiques pour les developpeurs
INFO	Normale	Messages operationnels de routine (demarrage, arret, requetes)
WARN	Elevee	Situations inattendues mais recuperables (API obsolete utilisee, nouvelle tentative necessaire)
ERROR	Haute	Echecs affectant une seule operation mais pas l’ensemble du systeme
FATAL	Critique	Echecs irrecuperables necessitant une attention immediate ou l’arret du systeme

En production, les logs sont generalement configures au niveau INFO ou WARN pour eviter le volume et la surcharge de performance des sorties DEBUG/TRACE. Les niveaux inferieurs sont actives temporairement lors des investigations d’incidents.

Cas d’usage courants

• Investigation d’incidents : Quand un service tombe en panne a 3h du matin, les logs sont le premier endroit ou les ingenieurs cherchent a comprendre ce qui s’est passe, dans quel ordre et pourquoi
• Audit de securite : Les logs d’authentification, d’acces et de pare-feu revelent les tentatives d’acces non autorise, les attaques par force brute et l’exfiltration de donnees
• Surveillance de la performance : L’analyse des champs de duree de requete dans les logs d’acces identifie les endpoints lents et les regressions de performance
• Conformite : Des reglementations comme PCI-DSS et RGPD exigent des pistes d’audit — les logs analyses fournissent des enregistrements consultables des acces aux donnees et des modifications du systeme
• Alertes : Les agregateurs de logs declenchent des alertes lorsque les taux d’erreur augmentent brusquement, que des modeles specifiques apparaissent ou que des services critiques tombent en panne