Logging (Structured)

DevOps 🟡 Mid

Définition

Logs au format JSON structuré avec des champs standardisés (timestamp, level, message, context). Facilite le parsing et la recherche.

Analogie

Un rapport de police avec des champs standardisés vs un texte libre : le premier est triable et cherchable.

Exemple de code

import pino from 'pino';
const logger = pino({ level: 'info' });
logger.info({ userId: '123', action: 'login', duration: 42 },
  'User logged in successfully'
);

Cas d'usage

Débugger en production en cherchant par userId, requestId ou level dans un outil comme ELK.

Anti-pattern

console.log partout en prod : pas structuré, pas de niveaux, pas de contexte.

Termes liés

#devops#monitoring#interview

En entretien

Explique-moi ce qu'est le logging structuré.
Ce sont des logs au format JSON avec des champs standardisés comme timestamp, level, message et context, ce qui facilite le parsing et la recherche. C'est comme un rapport de police avec des champs standardisés plutôt qu'un texte libre : le premier est triable et cherchable.
Pourquoi préférer le logging structuré à de simples console.log ?
Parce que console.log partout en prod n'est pas structuré, n'a pas de niveaux ni de contexte, ce qui est l'anti-pattern à éviter. Avec un outil comme pino, on peut logger logger.info({ userId, action, duration }, 'message') et retrouver facilement un événement.
Comment tu debuggerais un incident en production grâce au logging structuré ?
En cherchant dans un outil comme ELK par userId, requestId ou level, ce qui n'est possible que si les logs sont structurés en JSON avec des champs standardisés. C'est justement le use case principal de ce pattern.

Fiche mise à jour le 2026-09-27