Contexte d’observabilité actuel

Le modèle dominant d’observabilité repose sur la séparation stricte entre traces, métriques et logs, telle que présentée par OpenTelemetry. Cette plateforme décrit les trois types de télémétrie comme des entités distinctes, chacune avec son propre vocabulaire (spans, root spans, etc.). En pratique, cette classification crée une surcharge cognitive : les équipes doivent choisir entre plusieurs formats, comprendre plus d’une soixantaine de termes et adapter leurs pipelines d’instrumentation en fonction.

Principe des Wide Events de Scuba

Scuba, système interne de Meta, adopte une approche différente : chaque événement est un document JSON riche, appelé « Wide Event ». Un Wide Event regroupe un horodatage et un ensemble de paires clé‑valeur, sans contrainte de schéma. L’exemple fourni montre un enregistrement d’impression publicitaire contenant les champs Timestamp, AdId, UserCountry, Placement, CampaignType, UserOS, OSVersion et AppVersion. Cette permissivité permet d’ajouter immédiatement toute donnée jugée pertinente, même si son utilité future n’est pas encore connue.

{
    "Timestamp": "1707951423",
    "AdId": "542508c92f6f47c2916691d6e8551279",
    "UserCountry": "US",
    "Placement": "mobile_feed",
    "CampaignType": "direct_ads",
    "UserOS": "Android",
    "OSVersion": "14",
    "AppVersion": "798de3c28b074df9a24a479ce98302b6"
}

Mécanisme de sampling dynamique

Chaque Wide Event inclut un champ samplingRate qui indique le facteur de sous‑échantillonnage appliqué à cet enregistrement. L’interface de Scuba utilise ce champ pour recalculer automatiquement les agrégations présentées à l’utilisateur. Ainsi, le comptage d’impressions affiché correspond à la somme des taux d’échantillonnage plutôt qu’à un simple COUNT(*). La requête sous‑jacente ressemble à :

SELECT SUM(samplingRate) FROM AdImpressions WHERE IsTest = FALSE;

Cette logique élimine la nécessité de reconstituer manuellement les valeurs réelles, tout en autorisant des taux différents selon le type d’événement.

Analyse pratique : investigation par « slice and dice »

Lorsque l’on détecte une anomalie sur le tableau d’impressions, l’opérateur peut immédiatement filtrer ou regrouper les Wide Events par n’importe quel attribut. En l’occurrence, un regroupement par CampaignType révèle une catégorie suspecte, puis un second regroupement par UserOS indique que les appareils Android sont affectés. Un filtrage supplémentaire sur OSVersion montre que la version 14 de l’OS, combinée à certaines versions d’application, génère l’erreur. Cette chaîne d’explorations repose uniquement sur la richesse du schéma Wide Event et sur la capacité du moteur à recalculer les agrégations en temps réel.

Le processus illustre comment la granularité offerte par les Wide Events supprime le besoin de choisir a priori entre logs, métriques ou traces. Au lieu de cela, chaque donnée est stockée de façon uniforme, puis interrogée de manière flexible, ce qui réduit le temps d’identification des causes racines.