Introduction
La plupart des systèmes de journalisation sont trop étroits, ce qui peut entraîner des difficultés lors de la résolution des incidents. Stripe a développé un modèle de ligne de journal canonique, également appelé « wide events », qui consiste à émettre un enregistrement structuré par unité de travail avec tous les champs importants déjà attachés.
Contexte Technique
Un modèle de ligne de journal canonique est une ligne de journal qui résume une requête. Il doit inclure les champs que l'on souhaite toujours avoir en un seul endroit, tels que la méthode de routage, le statut, la durée, l'identifiant de l'utilisateur ou du compte, l'identifiant de la requête et l'identifiant de traçage, l'identifiant de construction ou de déploiement, les indicateurs de fonctionnalités, les temps de downstream, le code d'erreur, etc.
Ce modèle est utile car la ligne de journal est déjà pré-reliée, ce qui signifie que l'on n'a pas besoin de reconstruire une requête à partir de fragments. On peut interroger des lignes de journal complètes, ce qui change la façon dont on effectue le débogage en production.
Analyse et Implications
Stripe a traité la ligne de journal canonique comme une infrastructure critique. Elle est émise après la fin de la requête, et leur mise en œuvre est renforcée pour que la ligne apparaisse même en cas d'exceptions. De plus, Stripe n'a pas arrêté aux débogages. Ils ont poussé ces enregistrements dans des systèmes de stockage et les ont utilisés pour des analyses et des surfaces de produit à long terme, comme le tableau de bord du développeur.
Ce modèle de ligne de journal est plus qu'un journal plus agréable. C'est un modèle de données sous la forme d'une requête. Si le schéma est stable, le même événement peut supporter la réponse aux incidents, l'analyse des versions, les enquêtes de support client, l'analyse de produit, etc.
Perspective
Il est important de noter que la plupart des équipes s'arrêtent trop tôt dans leur processus de journalisation. Ils enregistrent la route, le statut et la latence, mais cela ne suffit pas pour le diagnostic. Les champs les plus précieux sont généralement les modèles de route, les identités, les métadonnées de version, les coûts d'exécution, les entrées de décision et les résultats.
Deux champs sont particulièrement sous-estimés : l'identifiant de construction et le code d'erreur. L'identifiant de construction permet de savoir quelle version est à l'origine d'une régression, tandis que le code d'erreur fournit un identifiant stable pour le site ou la raison exacte de l'échec.
Le véritable avantage de la journalisation large est la corrélation. Une fois que chaque requête porte le contexte commercial et le contexte d'exécution dans la même ligne, on peut poser des questions beaucoup plus précises. Les métriques sont mauvaises pour cela car elles éliminent le contexte trop tôt. Les journaux traditionnels sont mauvais pour cela car le contexte est éparpillé. Les lignes de journal canoniques conservent le contexte intact suffisamment longtemps pour l'interroger.
