OpenTelemetry-Tabellenreferenz für Zerobus Ingest

Diese Seite enthält Referenzinformationen für die OpenTelemetry-Tabellenschemas (OTLP) und die Datenzuordnung, die von Zerobus Ingest OTLP verwendet wird.

Tabellenschema

Wenn OTLP-Daten eingehen, konvertiert Zerobus Ingest jeden Datensatz aus der geschachtelten OTLP-Ressourcen-/Bereichs-/Datensatzhierarchie in eine flache, denormalisierte Zeile. Ressourcenattribute und Informationen zum Bereichsbereich werden direkt in jede Zeile eingebettet, sodass die Daten sofort ohne Verknüpfungen abfragt werden können.

Alle Attributfelder (attributes, resource.attributes, instrumentation_scope.attributesbody für Protokolle, metadata für Metriken) werden als VARIANT Spalten gespeichert. VARIANT ist ein halbstrukturierter Typ in Delta Lake, der JSON-Daten speichert und dabei die ursprünglichen Typen bewahrt.

Jeder Datensatz wird mit Datenbricks-spezifischen Feldern erweitert:

Feld Beschreibung Quelle
record_id Eine vom System generierte ID für eindeutige Identifikation und zeitgeordnete Sortierung. Generiert basierend auf der Zeit
time Zeitstempel in Mikrosekunden aus der Unix-Epoche. Zeitstempel (in Mikrosekunden) abgeleitet von start_time_unix_nano (Spans) oder time_unix_nano (Protokolle, Metriken)
date Datumspartitionsspalte zur effizienten Filterung des Zeitbereichs. Abgeleitet von time
service_name Spalte auf oberster Ebene zur effizienten Filterung nach Dienstnamen, wie in der OTel-Semantikkonvention definiert. Extrahiert aus resource.attributes["service.name"]

Numerische Genauigkeit und Vorzeichentypen

Aufgrund einiger Delta-Einschränkungen sollten Sie bitte Folgendes beachten:

  • Ganzzahlige Metrikwerte verlieren an Genauigkeit oberhalb von 2^53.Gauge, Sum, und Exemplar Datenpunkte, die ihren Wert als as_int64-Bit-Ganzzahl angeben, werden in DOUBLEumgewandelt, da Zerobus Ingest alle Metrikwerte in einer einzigen Gleitkommaspalte speichert. DOUBLE repräsentiert nur ganze Zahlen genau bis 2^53, etwa 9 Billiarden, sodass größere as_int Werte nach der Umrechnung an exakter Genauigkeit verlieren. Dies ist hauptsächlich für sehr große kumulative Zähler relevant, wie lebenslange Byte- oder Anfragesummen.
  • Unsignierte OTLP-Felder werden als signiert gespeichert. INT und BIGINT sind immer in Delta signiert, aber OTLP definiert einige numerische Felder als unsigniert (uint32, uint64, fixed64) oder als sehr große Zähler mit fester Breite. Felder wie *_time_unix_nano, flags, dropped_attributes_count, usw. werden as-is in einer signierten INT oder BIGINT Spalte gespeichert. Ein Wert über dem vorzeichenmäßigen Maximum (i32::MAX für INT, i64::MAX für BIGINT) wird zu einer negativen Zahl umgewickelt, anstatt Fehler zu erzeugen.

Schemazuordnung

Zerobus Ingest ordnet OTLP-Daten den Delta-Tabellenspalten zu, wie unten beschrieben.

Denormalisierung

Im OTLP-Protokoll werden Telemetriedaten wie folgt geschachtelt.

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

Zerobus Ingest vereinfacht diese Hierarchie, sodass jede Zeile den vollständigen Kontext enthält:

  • resource: Eine Struktur mit den Ressourcenattributen (as VARIANT) und dropped_attributes_count.
  • resource_schema_url: Die Schema-URL aus den eingeschlossenen ResourceSpans, ResourceLogs oder ResourceMetrics.
  • instrumentation_scope: Eine Struktur, die den Bereichsnamen, die Version, attribute (as VARIANT) und dropped_attributes_count.
  • span_schema_url / log_schema_url / metric_schema_url: Die Schema-URL aus den eingeschlossenen ScopeSpans, ScopeLogs oder ScopeMetrics.

ID-Codierung

trace_id, span_idund parent_span_id werden als hexadekodierte Zeichenfolgen in Kleinbuchstaben gespeichert:

  • trace_id: 32-stellige Hexzeichenfolge (16 Bytes)
  • span_id: 16-stellige Hexadexzeichenfolge (8 Bytes)

Enumerationscodierung

Enumerationswerte (kind, status.code, aggregation_temporality, severity_number) werden als ihre Zeichenfolgennamen gespeichert, wie in der OTLP-Spezifikation definiert. Beispiel: SPAN_KIND_SERVER, , STATUS_CODE_OKAGGREGATION_TEMPORALITY_DELTA.

Nächste Schritte

  • Last updated on