Aller au contenu principal

Référence de table OpenTelemetry pour Zerobus Ingest

info

Bêta

Cette fonctionnalité est en Bêta.

Cette page fournit des informations de référence sur les schémas de table OpenTelemetry (OTLP) et le mappage des données utilisés par Zerobus Ingest OTLP.

Schéma de table

Lorsque les données OTLP arrivent, Zerobus Ingest convertit chaque enregistrement de la hiérarchie imbriquée OTLP resource/scope/record en une ligne plate et dénormalisée. Les attributs des ressources et les informations de portée d’instrumentation sont intégrés directement dans chaque ligne, ce qui rend les données immédiatement interrogeables sans jointure.

Tous les champs d'attribut (attributes, resource.attributes, instrumentation_scope.attributes, body pour les Logs, metadata pour les métriques) sont stockés en tant que VARIANT colonnes. VARIANT est un type semi-structuré dans Delta Lake qui stocke les données JSON tout en préservant les types originaux.

Chaque enregistrement est augmenté de champs spécifiques à Databricks :

Champ

Description

Source

record_id

Un ID généré par le système pour une identification unique et un tri par ordre chronologique.

Généré en fonction du temps.

time

Timestamp en microsecondes à partir de l'époque Unix.

Timestamp (en microsecondes) dérivé de start_time_unix_nano (spans) ou time_unix_nano (logs, métriques)

date

Colonne de partition de date, pour un filtrage efficace par plage horaire.

Dérivé de time

service_name

Colonne de niveau supérieur pour un filtrage efficace par nom de service, tel que défini dans la convention sémantique OTel.

Extrait de resource.attributes["service.name"]

Champ

Description

Source

record_id

Un ID généré par le système pour une identification unique et un tri par ordre chronologique.

Généré en fonction du temps.

time

Timestamp en microsecondes à partir de l'époque Unix.

Timestamp (en microsecondes) dérivé de start_time_unix_nano (spans) ou time_unix_nano (logs, métriques)

date

Colonne de partition de date, pour un filtrage efficace par plage horaire.

Dérivé de time

service_name

Colonne de niveau supérieur pour un filtrage efficace par nom de service, tel que défini dans la convention sémantique OTel.

Extrait de resource.attributes["service.name"]

Mappage de schéma

Zerobus Ingest met en correspondance les données OTLP avec les colonnes de table Delta, comme décrit ci-dessous.

Dénormalisation

Dans le protocole OTLP, les données de télémétrie sont imbriquées comme suit.

ResourceSpans (or ResourceLogs, ResourceMetrics)
└── Resource (attributes, schema_url)
└── ScopeSpans (or ScopeLogs, ScopeMetrics)
└── InstrumentationScope (name, version, attributes)
└── Span (or LogRecord, Metric)

Zerobus Ingest aplanit cette hiérarchie afin que chaque ligne contienne le contexte complet :

  • resource: Une struct contenant les attributs de ressource (en tant que VARIANT) et dropped_attributes_count.
  • resource_schema_url: L'URL du schéma des ResourceSpans, ResourceLogs ou ResourceMetrics englobants.
  • instrumentation_scope: Une structure contenant le nom de la portée, la version, les attributs (comme VARIANT) et dropped_attributes_count.
  • span_schema_url / log_schema_url / metric_schema_url: l'URL du schéma provenant des ScopeSpans, ScopeLogs ou ScopeMetrics englobants.

Encodage de l'ID

trace_id, span_id et parent_span_id sont stockés sous forme de chaînes hexadécimales encodées en minuscules :

  • trace_id: chaîne hexadécimale de 32 caractères (16 octets)
  • span_id: chaîne hexadécimale de 16 caractères (8 octets)

Encodage d'énumération

Les valeurs d'énumération (kind, status.code, aggregation_temporality, severity_number) sont stockées en tant que noms de chaîne tels que définis dans la spécification OTLP. Par exemple : SPAN_KIND_SERVER, STATUS_CODE_OK, AGGREGATION_TEMPORALITY_DELTA.

Étapes suivantes