Pular para o conteúdo principal

Tabela de referência OpenTelemetry para ingestão Zerobus

Esta página fornece informações de referência para os esquemas de tabelas e mapeamento de dados do OpenTelemetry (OTLP) usados pelo Zerobus Ingest OTLP.

Esquema da tabela​

Quando os dados OTLP chegam, o Zerobus Ingest converte cada registro da hierarquia aninhada de recursos/escopos/registros OTLP em uma linha plana e desnormalizada. Os atributos de recurso e as informações de escopo de instrumentação estão incorporados diretamente em cada linha, tornando os dados imediatamente consultáveis sem necessidade de junção.

Todos os campos de atributos (attributes, resource.attributes, instrumentation_scope.attributes, body para logs, metadata para métricas) são armazenados como colunas VARIANT . VARIANT é um tipo semiestruturado no Delta Lake que armazena dados JSON, preservando os tipos originais.

Cada registro é enriquecido com campos específicos do Databricks:

campo

Descrição

Origem

record_id

Um ID gerado pelo sistema para identificação única e classificação por ordem cronológica.

Gerado com base no tempo

time

Data e hora em microssegundos a partir da época Unix.

Timestamp (em microssegundos) derivado de start_time_unix_nano (spans) ou time_unix_nano (logs, métricas)

date

Coluna de partição de data, para filtragem eficiente por intervalo de tempo.

Derivado de time

service_name

Coluna de nível superior para filtragem eficiente por nome de serviço, conforme definido na convenção semântica OTel.

Extraído de resource.attributes["service.name"]

campo

Descrição

Origem

record_id

Um ID gerado pelo sistema para identificação única e classificação por ordem cronológica.

Gerado com base no tempo

time

Data e hora em microssegundos a partir da época Unix.

Timestamp (em microssegundos) derivado de start_time_unix_nano (spans) ou time_unix_nano (logs, métricas)

date

Coluna de partição de data, para filtragem eficiente por intervalo de tempo.

Derivado de time

service_name

Coluna de nível superior para filtragem eficiente por nome de serviço, conforme definido na convenção semântica OTel.

Extraído de resource.attributes["service.name"]

Precisão numérica e tipos assinados​

Devido a algumas limitações de tipo do Delta, esteja atento ao seguinte:

  • Valores de métricas inteiras perdem precisão acima de 2^53. Os pontos de dados Gauge, Sum e Exemplar que relatam seu valor como as_int, um número inteiro de 64 bits, são convertidos para DOUBLE, uma vez que o Zerobus Ingest armazena todos os valores de métricas em uma única coluna de ponto flutuante. DOUBLE representa apenas números inteiros exatamente até 2^53, cerca de 9 quatrilhões, portanto, valores as_int maiores perdem a precisão exata após a conversão. Isso é importante principalmente para contadores cumulativos muito grandes, como totais de bytes ou de solicitações durante todo o período.
  • Campos OTLP não assinados são armazenados como assinados. INT e BIGINT são sempre assinados no Delta, mas o OTLP define alguns campos numéricos como não assinados (uint32, uint64, fixed64) ou como contadores de largura fixa muito grandes. Campos como *_time_unix_nano, flags, dropped_attributes_count, etc., são armazenados como estão em uma coluna INT ou BIGINT assinada. Um valor acima do máximo assinado (i32::MAX para INT, i64::MAX para BIGINT) é convertido para um número negativo em vez de gerar um erro.

Mapeamento de esquema​

O Zerobus Ingest mapeia os dados OTLP para as colunas da tabela Delta conforme descrito abaixo.

Desnormalização​

No protocolo OTLP, os dados de telemetria são aninhados da seguinte forma.

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

O Zerobus Ingest simplifica essa hierarquia, de forma que cada linha contenha o contexto completo:

  • resource: Uma estrutura contendo os atributos do recurso (como VARIANT) e dropped_attributes_count.
  • resource_schema_url: O URL do esquema dos ResourceSpans, ResourceLogs ou ResourceMetrics que os contêm.
  • instrumentation_scope: Uma estrutura contendo o nome do escopo, versão, atributos (como VARIANT) e dropped_attributes_count.
  • span_schema_url / log_schema_url / metric_schema_url: O URL do esquema dos ScopeSpans, ScopeLogs ou ScopeMetrics que o contêm.

Codificação de ID​

trace_id, span_id e parent_span_id são armazenados como strings codificadas em hexadecimal em letras minúsculas:

  • trace_idCadeias hexadecimais de 32 caracteres (16 bytes)
  • span_idCadeias hexadecimais de 16 caracteres (8 bytes)

Codificação Enum​

Os valores de enumeração (kind, status.code, aggregation_temporality, severity_number) são armazenados como seus nomes de string conforme definido na especificação OTLP. Por exemplo: SPAN_KIND_SERVER, STATUS_CODE_OK, AGGREGATION_TEMPORALITY_DELTA.

Próximos passos​