Ereignisablaufverfolgung: Weitergabe von Ablaufverfolgungs-IDs von übergeordneten zu untergeordneten Objekten durch Prozeduraufrufe¶

Vor der Änderung:

Der trace_id-Wert jedes Bereichs (Span), der durch verkettete gespeicherte Prozeduren oder UDFs in Java oder Scala erstellt wird, ist eindeutig.

Das Feld parent_span_id ist nicht in der RECORD-Spalte der Ereignistabelle vorhanden.

Anbietern und Verbrauchern von Native Apps werden unterschiedliche trace_id-Werte für freigegeben Ereignisse angezeigt. Anbietern wird die Hash-Version angezeigt.

Nach der Änderung:

Bereiche (Spans), die durch verkettete gespeicherte Prozeduren oder UDFs in Java oder Scala generiert werden, haben denselben trace_id-Wert. Die Spalte RECORD hat ein Attribut parent_span_id.

Bereiche (Spans), die durch verkettete gespeicherte Prozeduren oder UDFs in Python generiert werden, haben eine Übergeordnet/Untergeordnet-Beziehung zwischen parent_span_id und span_id. Gespeicherte Prozeduren in Java oder Scala können andere gespeicherte Prozeduren in einer beliebig langen Kette aufrufen. (UDFs können keine SQL-Anweisungen ausführen, sodass der Aufruf einer UDF die Kette beendet. Die Ablaufverfolgungsinformationen werden jedoch weiterhin an den Bereich (Span) der UDF weitergegeben.)

Wenn die gespeicherte Prozedur oder die UDF in Java oder Scala direkt vom Benutzer (dem Stamm) aufgerufen wird, ist der trace_id-Wert eine zufällige ID und es gibt keinen parent_span_id-Wert. Wenn die Ablaufverfolgung für eine gespeicherte Prozedur deaktiviert ist und diese eine andere gespeicherte Prozedur oder UDF aufruft, dann ist der trace_id-Wert der untergeordneten Bereiche (Spans) zufällig und es gibt keinen parent_span_id-Wert. Mit anderen Worten: Die Ablaufverfolgung wird beim untergeordneten Element neu gestartet.

Anbietern und Verbrauchern von Native Apps wird derselbe trace_id-Wert für freigegebene Ereignisse von gespeicherten Prozeduren oder UDFs in Java oder Scala angezeigt, sodass sie leichter zu debuggen sind.

Ref.: 1592