Dokumentacja tabeli OpenTelemetry dla pozyskiwania z modelu Zerobus

Ta strona zawiera informacje referencyjne dotyczące schematów tabel OpenTelemetry (OTLP) i mapowania danych używanych przez Zerobus Ingest OTLP.

Schemat tabeli

Po nadejściu danych OTLP pozyskiwanie zerobus konwertuje każdy rekord z zagnieżdżonego zasobu OTLP/zakresu/hierarchii rekordów w płaski, zdenormalizowany wiersz. Atrybuty zasobów i informacje o zakresie instrumentacji są osadzone bezpośrednio w każdym wierszu, dzięki czemu dane są natychmiast możliwe do wykonywania zapytań bez sprzężeń.

Wszystkie pola atrybutów (attributes, resource.attributes, instrumentation_scope.attributesbody, dla dzienników, metadata dla metryk) są przechowywane jako VARIANT kolumny. VARIANT jest częściowo ustrukturyzowanym typem w usłudze Delta Lake, który przechowuje dane JSON przy zachowaniu oryginalnych typów.

Każdy rekord jest rozszerzany o pola specyficzne dla usługi Databricks:

Pole Opis Źródło
record_id Identyfikator wygenerowany przez system na potrzeby unikatowej identyfikacji i sortowania uporządkowanego czasowo. Generowane na podstawie czasu
time Sygnatura czasowa w mikrosekundach z epoki Unix. Sygnatura czasowa (w mikrosekundach) pochodząca z start_time_unix_nano (zakresów) lub time_unix_nano (dzienniki, metryki)
date Kolumna partycji daty na potrzeby efektywnego filtrowania zakresu czasu. Pochodzi z time
service_name Kolumna najwyższego poziomu do wydajnego filtrowania według nazwy usługi, zgodnie z definicją w konwencji semantycznej OTel. Wyodrębnione z resource.attributes["service.name"]

Precyzja numeryczna i typy znakowane

Ze względu na pewne ograniczenia typu Delta, prosimy pamiętać o następujących kwestiach:

  • Wartości metryk całkowitych tracą precyzję powyżej 2^53.Gauge, Sum, a punkty Exemplar danych, które podają swoją wartość jako as_int, 64-bitową liczbę całkowitą, są przekształcane w DOUBLE, ponieważ Zerobus Ingest przechowuje wszystkie wartości metryki w jednej kolumnie zmiennoprzecinkowej. DOUBLE oznacza tylko liczby całkowite dokładnie do 2^53, czyli około 9 kwadrylionów, więc większe as_int wartości tracą dokładną precyzję po przeliczeniu. Dotyczy to głównie bardzo dużych liczników skumulowanych, takich jak liczba bajtów żywotnych lub liczb żądań.
  • Pola OTLP bez znaku są przechowywane jako podpisane. INT i BIGINT są zawsze znakowane w Delcie, ale OTLP definiuje niektóre pola numeryczne jako nieznakomitne (uint32, uint64, fixed64) lub jako bardzo duże liczniki o stałej szerokości. Pola takie jak *_time_unix_nano, flags, dropped_attributes_count, itd. są przechowywane as-is w znaku INT lub BIGINT kolumnie. Wartość powyżej znakowanego maksimum (i32::MAX dla INT, i64::MAX dla BIGINT) zawija się do liczby ujemnej zamiast błędu.

Mapowanie schematu

Pozyskiwanie zerobus mapuje dane OTLP na kolumny tabeli delty zgodnie z poniższym opisem.

Denormalizacja

W protokole OTLP dane telemetryczne są zagnieżdżone w następujący sposób.

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

Zerobus Ingest spłaszcza tę hierarchię, tak aby każdy wiersz zawierał pełny kontekst:

  • resource: struktura zawierająca atrybuty zasobu (jako VARIANT) i dropped_attributes_count.
  • resource_schema_url: adres URL schematu z otaczającego obszaru ResourceSpans, ResourceLogs lub ResourceMetrics.
  • instrumentation_scope: struktura zawierająca nazwę zakresu, wersję, atrybuty (jako VARIANT) i dropped_attributes_count.
  • span_schema_url / log_schema_url / metric_schema_url: adres URL schematu z otaczającego zakresuSpans, scopeLogs lub ScopeMetrics.

Kodowanie identyfikatorów

trace_id, span_idi parent_span_id są przechowywane jako małe ciągi kodowane literami szesnastkowymi:

  • trace_id: 32-znakowy ciąg szesnastkowy (16 bajtów)
  • span_id: 16-znakowy ciąg szesnastkowy (8 bajtów)

Kodowanie wyliczenia

Wartości wyliczenia (kind, status.code, , aggregation_temporalityseverity_number) są przechowywane jako ich nazwy ciągów zgodnie ze specyfikacją OTLP. Na przykład: SPAN_KIND_SERVER, , STATUS_CODE_OKAGGREGATION_TEMPORALITY_DELTA.

Następne kroki

  • Last updated on