Aller au contenu principal
Dernière mise à jour le

Référence de table OpenTelemetry pour Zerobus Ingest

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"]

Précision numérique et types signés​

En raison de certaines limitations liées au type Delta, veuillez tenir compte des points suivants :

  • Les valeurs de métriques entières perdent en précision au-delà de 2^53. Les points de données Gauge, Sum et Exemplar qui rapportent leur valeur sous forme de as_int, un entier 64 bits, sont convertis en DOUBLE, car Zerobus Ingest stocke toutes les valeurs de métriques dans une seule colonne à virgule flottante. DOUBLE ne représente les entiers exactement que jusqu'à 2^53, soit environ 9 quadrillions ; les valeurs as_int plus grandes perdent donc leur précision exacte une fois converties. Cela concerne principalement les très grands compteurs cumulatifs, tels que les totaux d'octets ou de requêtes sur la durée de vie.
  • Les champs OTLP non signés sont stockés en tant que champs signés. INT et BIGINT sont toujours signés dans Delta, mais OTLP définit certains champs numériques comme non signés (uint32, uint64, fixed64) ou comme des compteurs à largeur fixe très grands. Les champs tels que *_time_unix_nano, flags, dropped_attributes_count, etc., sont stockés tels quels dans une colonne INT ou BIGINT signée. Une valeur supérieure au maximum signé (i32::MAX pour INT, i64::MAX pour BIGINT) est convertie en nombre négatif au lieu de générer une erreur.

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​

Sur cette page