Le logging est un désastre

• Dans les systèmes distribués modernes, les approches de logging traditionnelles ont une limite structurelle : elles ne parviennent pas à restituer la vérité
• Les logs restent conçus selon l’hypothèse d’un environnement à serveur unique façon 2005, et perdent donc le contexte d’une requête qui traverse plusieurs services, bases de données et caches
• Une simple recherche de chaînes ne comprend ni la structure, ni les relations, ni les corrélations, ce qui rend la recherche de la cause d’un problème difficile
• La solution consiste à enregistrer pour chaque requête un unique “Wide Event” (ou “Canonical Log Line”) contenant tout le contexte
• Cela transforme les logs, qui ne sont plus un simple texte mais un actif de données exploitable pour l’analyse

---

Le problème fondamental du logging

• Les logs traditionnels ont été conçus à l’époque des serveurs monolithiques et ne reflètent pas l’architecture moderne des services distribués
  • Une requête traverse plusieurs services, bases de données, caches et files de messages, mais les logs continuent d’être écrits comme s’ils provenaient d’un seul serveur
• Dans l’exemple de logs, une seule requête génère 13 lignes ; avec 10 000 utilisateurs simultanés, cela représente 130 000 lignes par seconde, dont la plupart n’apportent rien
• En cas d’incident, ce qu’il faut, c’est du contexte, or les logs actuels en manquent

Les limites de la recherche textuelle

• Lorsqu’un utilisateur signale que « le paiement ne fonctionne pas », chercher dans les logs par e-mail ou par user_id donne rarement des résultats utiles, faute de structure cohérente
  • Le même identifiant utilisateur peut être enregistré sous des dizaines de formes : user-123, user_id=user-123, {"userId":"user-123"}, etc.
• Les formats de logs diffèrent d’un service à l’autre, ce qui rend impossible le suivi des événements liés
• Le problème central est que les logs sont conçus pour l’écriture (write), et non optimisés pour la requête (query)

Définitions des concepts clés

• Structured Logging : méthode qui consiste à enregistrer les événements sous forme de paires clé-valeur (JSON) plutôt que comme de simples chaînes
• Cardinality : nombre de valeurs distinctes d’un champ ; par exemple, user_id a une cardinalité très élevée
• Dimensionality : nombre de champs dans un événement de log ; plus il y en a, plus le potentiel d’analyse est élevé
• Wide Event / Canonical Log Line : un seul événement de log riche en contexte par requête
• La plupart des systèmes de logging limitent les données à forte cardinalité pour des raisons de coût, alors qu’en pratique ce sont souvent les plus utiles pour le débogage

Les limites d’OpenTelemetry

• OpenTelemetry (OTel) est un ensemble de protocoles et de SDK qui ne fournit qu’un standard de collecte et de transport des données
• En revanche, OTel ne fait pas les choses suivantes
  1. il ne décide pas quoi logger
  2. il n’ajoute pas automatiquement le contexte métier (par exemple : niveau d’abonnement, montant du panier, etc.)
  3. il ne change pas la façon de penser le logging des développeurs
• Même avec la même bibliothèque, l’expérience de débogage est radicalement différente entre une instrumentation qui ajoute volontairement du contexte et une instrumentation minimale
• OTel n’est qu’une simple tuyauterie (plumbing) ; c’est au développeur de décider ce qu’il y fait circuler

L’approche Wide Event / Canonical Log Line

• Il faut abandonner un logging centré sur « ce que fait le code » pour enregistrer plutôt « ce qui est arrivé à la requête »
• Pour chaque requête, on génère un événement large au niveau du service
  • Il peut inclure plus de 50 champs liés à la requête, à l’utilisateur, au paiement, aux erreurs, à l’environnement, etc.
• Dans l’exemple JSON, user_id, subscription_tier, service_version, error_code et tous les autres éléments de contexte utiles au débogage sont présents
• Cela permet, en une seule recherche, d’analyser immédiatement des questions comme « pourquoi les paiements échouent-ils chez les utilisateurs premium ? »

Utilisation des requêtes sur les Wide Events

• Les Wide Events ne se traitent pas comme une simple recherche textuelle, mais via des requêtes sur des données structurées
• Grâce à des données de forte cardinalité et de grande dimension, on peut faire du débogage au niveau d’une analyse en temps réel
• Exemple : exécuter immédiatement une requête du type « agréger le taux d’échec des paiements des utilisateurs premium au cours de la dernière heure, par code d’erreur »

Schéma d’implémentation

• On construit l’événement tout au long du cycle de vie de la requête, puis on ne l’émet qu’une seule fois à la fin
  • Dans le middleware, on initialise les champs de base comme request_id, timestamp, method, path, etc.
  • Dans le handler, on ajoute progressivement les informations sur l’utilisateur, le panier, le paiement et les erreurs
• Au final, on enregistre un unique événement JSON avec logger.info(event)

Contrôler les coûts par l’échantillonnage

• Enregistrer plus de 50 champs par requête fait rapidement grimper les coûts ; il faut donc échantillonner
• Un échantillonnage purement aléatoire risque de laisser passer des erreurs
• Une stratégie de Tail Sampling est proposée
  1. les erreurs (500, etc.) sont toujours conservées
  2. les requêtes lentes (p99 et au-delà) sont toujours conservées
  3. les utilisateurs VIP et les sessions marquées par certains flags sont toujours conservés
  4. pour le reste, seuls 1 à 5 % sont échantillonnés aléatoirement
• Cela permet à la fois de réduire les coûts et de préserver les événements clés

Clarification de quelques idées reçues

• Structured Logging ≠ Wide Event : un format JSON ne suffit pas ; le contexte est l’élément essentiel
• Utiliser OpenTelemetry ≠ obtenir une observabilité complète : la collecte est standardisée, mais le contenu des logs reste de la responsabilité du développeur
• Ce n’est pas la même chose que le tracing : le tracing montre le flux entre services, tandis que le Wide Event fournit le contexte interne au service
• La séparation « les logs servent au débogage, les métriques aux dashboards » n’est pas nécessaire — les Wide Events couvrent les deux usages
• L’idée selon laquelle les données à forte cardinalité coûtent cher est dépassée ; des bases modernes comme ClickHouse et BigQuery les traitent efficacement

Les effets de l’adoption des Wide Events

• Le débogage passe de l’archéologie à l’analyse
• Au lieu de faire des grep dans les logs de 50 services pour retrouver un « échec de paiement utilisateur »,
  on passe à une analyse fondée sur une requête unique, du type « consulter le taux d’échec des paiements des utilisateurs premium par code d’erreur »
• Au final, les logs cessent d’être un outil qui ment, pour devenir un actif de données qui dit la vérité