Rastreamento de eventos: IDs de rastreamento propagado do pai para o filho por meio de chamadas de procedimento

Atenção

Essa mudança de comportamento está no pacote 2024_04.

Para saber o status atual do pacote, consulte Histórico do pacote.

Antes da mudança:

O trace_id de cada um dos intervalos criados por procedimentos armazenados Java e Scala encadeados ou UDFs é exclusivo.

O campo parent_span_id não existe na coluna RECORD da tabela de eventos.

Provedores e consumidores de Native Apps veem valores trace_id diferentes para eventos compartilhados. O provedor vê a versão com hash.

Após a mudança:

Os spans gerados por procedimentos armazenados Java e Scala encadeados ou UDFs têm o mesmo trace_id. A coluna RECORD tem um atributo parent_span_id.

Os spans gerados por procedimentos armazenados Java e Scala encadeados ou UDFs têm um relacionamento pai-filho entre parent_span_id e span_id. Procedimentos armazenados Java e Scala podem chamar outros procedimentos armazenados em uma cadeia de qualquer comprimento. (UDFs não podem executar instruções SQL, então a chamada de uma UDF termina a cadeia. No entanto, as informações de rastreamento ainda são propagadas para os spans da UDF.)

Se o procedimento armazenado Java ou Scala ou UDF foi chamado diretamente pelo usuário (a raiz), então trace_id será um ID aleatório e não haverá parent_span_id. Se o rastreamento estiver desabilitado para um procedimento armazenado e chamar outro procedimento armazenado ou UDF, então o trace_id dos intervalos do filho será aleatório e não terá parent_span_id. Em outras palavras, o rastreamento é reiniciado no filho.

Provedores e consumidores de Native Apps veem o mesmo trace_id para procedimentos armazenados Java ou Scala compartilhados ou eventos da UDF, para que possam ser depurados com mais facilidade.

Ref: 1592