Traçage d’événements : traçage d’IDs propagé de parent à enfant par des appels de procédure¶

Avant la modification:

Le trace_id de chacun des spans créés par des procédures stockées Java et Scala chaînées ou des UDFs est unique.

Le champ parent_span_id n’existe pas dans la colonne RECORD de la table d’événements.

Les fournisseurs et les consommateurs de Native apps voient des valeurs trace_id différentes pour les événements partagés. Le fournisseur voit la version hachée.

Après la modification:

Les spans générés par des procédures stockées Java et Scala enchaînées ou des UDFs ont le même trace_id. La colonne RECORD a un attribut parent_span_id.

Les spans générés par les procédures stockées Java et Scala chaînées ou des UDFs ont une relation parent-enfant entre parent_span_id et span_id. Les procédures stockées Java et Scala peuvent appeler d’autres procédures stockées dans une chaîne de n’importe quelle longueur. (Comme les UDFs ne peuvent pas exécuter d’instructions SQL, l’appel à une UDF met fin à la chaîne. Cependant, les informations de trace sont toujours propagées aux spans de l’UDF.)

Si la procédure stockée Java ou Scala ou l’UDF a été appelée par l’utilisateur directement (la racine), alors le trace_id sera un ID aléatoire et il n’y aura pas de parent_span_id. Si le traçage est désactivé pour une procédure stockée et qu’il appelle une autre procédure stockée ou une UDF, les trace_id des spans de l’enfant seront aléatoires et n’auront pas de parent_span_id. En d’autres termes, la trace est redémarrée au niveau de l’enfant.

Les fournisseurs et les consommateurs de Native apps voient le même trace_id pour les procédures stockées Java ou Scala partagées ou les événements UDF, ce qui permet de les déboguer plus facilement.

Réf : 1592