Informazioni di riferimento sulla tabella OpenTelemetry per l'inserimento Zerobus

Questa pagina fornisce informazioni di riferimento per gli schemi di tabella OpenTelemetry (OTLP) e il mapping dei dati usati da Zerobus Ingest OTLP.

Schema tabella

Quando arrivano i dati OTLP, Zerobus Ingest converte ogni record dalla gerarchia di risorse/ambito/record OTLP annidata in una riga flat denormalizzata. Gli attributi delle risorse e le informazioni sull'ambito di strumentazione vengono incorporati direttamente in ogni riga, rendendo i dati immediatamente eseguibili senza join.

Tutti i campi degli attributi (, , , attributes per i log, resource.attributes per le metriche) vengono archiviati come instrumentation_scope.attributesbodycolonne. metadataVARIANT VARIANT è un tipo semistrutturato in Delta Lake che archivia i dati JSON mantenendo i tipi originali.

Ogni record viene aumentato con i campi specifici di Databricks:

Campo Descrizione origine
record_id ID generato dal sistema per l'identificazione univoca e l'ordinamento ordinato in base al tempo. Generato in base al tempo
time Timestamp in microsecondi dall'epoca Unix. Timestamp (in microsecondi) derivato da start_time_unix_nano (intervalli) o time_unix_nano (log, metriche)
date Colonna della partizione di data, per un filtro efficiente dell'intervallo di tempo. Derivato da time
service_name Colonna di primo livello per un filtro efficiente in base al nome del servizio, come definito nella convenzione semantica OTel. Estratto da resource.attributes["service.name"]

Precisione numerica e tipi firmati

A causa di alcune limitazioni di tipo Delta, si prega di tenere presente quanto segue:

  • I valori interi delle metriche perdono precisione sopra 2^53.Gauge, Sum, e Exemplar i punti dati che riportano il loro valore come as_int, un intero a 64 bit, vengono convertiti in DOUBLE, poiché Zerobus Ingest memorizza tutti i valori delle metriche in una singola colonna a virgola mobile. DOUBLE rappresenta solo interi esattamente fino a 2^53, circa 9 quadrilioni, quindi valori più grandi as_int perdono precisione esatta una volta convertiti. Questo è importante soprattutto per contatori cumulativi molto grandi, come i totali di byte o richieste a vita.
  • I campi OTLP non firmati sono memorizzati come firmati. INT e BIGINT sono sempre firmati in Delta, ma OTLP definisce alcuni campi numerici come non segni (uint32, uint64, fixed64) o come contatori a larghezza fissa molto grandi. Campi come *_time_unix_nano, , , flagsecc., sono memorizzati as-is in una colonna o firmata dropped_attributes_countINT. BIGINT Un valore superiore al massimo firmato (i32::MAX per INT, i64::MAX per BIGINT) si avvolge in un numero negativo invece di causare errori.

Mapping dello schema

Zerobus Ingest esegue il mapping dei dati OTLP alle colonne della tabella Delta, come descritto di seguito.

Denormalizzazione

Nel protocollo OTLP i dati di telemetria sono annidati così.

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

Zerobus Ingest rende flat questa gerarchia in modo che ogni riga contenga il contesto completo:

  • resource: uno struct contenente gli attributi della risorsa (come VARIANT) e dropped_attributes_count.
  • resource_schema_url: URL dello schema dall'oggetto ResourceSpans, ResourceLogs o ResourceMetrics contenitore.
  • instrumentation_scope: uno struct contenente il nome dell'ambito, la versione, gli attributi (come VARIANT) e dropped_attributes_count.
  • span_schema_url / log_schema_url / metric_schema_url: URL dello schema dall'oggetto ScopeSpans, ScopeLogs o ScopeMetrics.

Codifica ID

trace_id, span_ide parent_span_id vengono archiviati come stringhe con codifica hex minuscole:

  • trace_id: stringa esadecimale di 32 caratteri (16 byte)
  • span_id: stringa esadecimale di 16 caratteri (8 byte)

Codifica enumerazione

I valori di enumerazione (kind, status.code, aggregation_temporality, severity_number) vengono archiviati come nomi di stringa, come definito nella specifica OTLP. Ad esempio: SPAN_KIND_SERVER, STATUS_CODE_OK, AGGREGATION_TEMPORALITY_DELTA.

Passaggi successivi