OpenTelemetry-tabellreferens för Zerobus-inmatning

Den här sidan innehåller referensinformation för OpenTelemetry-tabellscheman (OTLP) och datamappning som används av Zerobus Ingest OTLP.

Tabellschema

När OTLP-data tas emot konverterar Zerobus Ingest varje post från den kapslade OTLP-resursen/omfångs-/posthierarkin till en platt, avnormaliserad rad. Information om resursattribut och instrumenteringsomfång bäddas in direkt på varje rad, vilket gör att data omedelbart kan köras utan kopplingar.

Alla attributfält (attributes, resource.attributes, instrumentation_scope.attributes, body för loggar för metadata mått) lagras som VARIANT kolumner. VARIANT är en halvstrukturerad typ i Delta Lake som lagrar JSON-data samtidigt som de ursprungliga typerna bevaras.

Varje post utökas med Databricks-specifika fält:

Fält Beskrivning Källa
record_id Ett systemgenererat ID för unik identifiering och tidsbeställd sortering. Genereras baserat på tid
time Tidsstämpel i mikrosekunder från Unix-epoken. Tidsstämpel (i mikrosekunder) som härletts från start_time_unix_nano (intervall) eller time_unix_nano (loggar, mått)
date Datumpartitionskolumn för effektiv filtrering av tidsintervall. Härledd från time
service_name Kolumnen på den översta nivån för effektiv filtrering efter tjänstnamn, enligt definitionen i OTel-semantikkonventionen. Extraherad från resource.attributes["service.name"]

Numerisk precision och signerade typer

På grund av vissa begränsningar för Delta-typen, var vänlig och tänk på följande:

  • Heltalsmetriska värden förlorar precision över 2^53.Gauge, Sum, och Exemplar datapunkter som rapporterar sitt värde som as_int, ett 64-bitars heltal, konverteras till DOUBLE, eftersom Zerobus Ingest lagrar alla metriska värden i en enda flyttalskolumn. DOUBLE representerar endast heltal exakt upp till 2^53, ungefär 9 biljarder, så större as_int värden förlorar exakt precision när de konverteras. Detta är främst viktigt för mycket stora kumulativa räknare, såsom livstidsbyte eller totalsummor för förfrågningar.
  • Osignerade OTLP-fält lagras som signerade. INT och BIGINT är alltid signerade i Delta, men OTLP definierar vissa numeriska fält som osignerade (uint32, uint64, fixed64) eller som mycket stora räknare med fast bredd. Fält som *_time_unix_nano, flags, dropped_attributes_count, etc. lagras as-is i en signerad INT eller BIGINT kolumn. Ett värde över det signerade maximumet (i32::MAX för INT, i64::MAX för BIGINT) omsluts till ett negativt tal istället för att ge fel.

Kartläggning av schema

Zerobus Ingest mappar OTLP-data till Delta-tabellkolumner enligt beskrivningen nedan.

Avormalisering

I OTLP-protokollet kapslas telemetridata så här.

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

Zerobus Ingest plattar ut den här hierarkin så att varje rad innehåller hela kontexten:

  • resource: En struct som innehåller resursattributen (som VARIANT) och dropped_attributes_count.
  • resource_schema_url: Schema-URL:en från omslutande ResourceSpans, ResourceLogs eller ResourceMetrics.
  • instrumentation_scope: En struct som innehåller omfångsnamnet, versionen, attributen (som VARIANT) och dropped_attributes_count.
  • span_schema_url / log_schema_url / metric_schema_url: Schema-URL:en från omslutande ScopeSpans, ScopeLogs eller ScopeMetrics.

ID-kodning

trace_id, span_idoch parent_span_id lagras som gemener hexkodade strängar:

  • trace_id: Hexsträng med 32 tecken (16 byte)
  • span_id: Hexsträng med 16 tecken (8 byte)

Uppräkningskodning

Uppräkningsvärden (kind, status.code, aggregation_temporality, severity_number) lagras som deras strängnamn enligt definitionen i OTLP-specifikationen. Till exempel: SPAN_KIND_SERVER, STATUS_CODE_OK, AGGREGATION_TEMPORALITY_DELTA.

Nästa steg

  • Last updated on