trace_id check to accepts dashes as UUID format about router HOT 6 OPEN

related to this too. #5056

from router.

Hey @abernix. Thanks for sharing. I had a quick look but from my understanding, if it is stripping the dashes, how does that provide continuity using the same trace_id on the request, or am I missing something?

from router.

Do you think this is ultimately the same as #4892? If so, it should/could be fixed by #5071? (It was recently opened).

Can you take a look?

from router.

@BrynCooke You're pretty connected to the work here - Can you advise? (Look carefully they're both different nuances of dashes in trace IDs)

from router.

@juancarlosjr97 Trace ID in opentelemetry is represented as a 128 bit number. This is usually represented as a hex string without dashes and is based on w3c trace id format.

The UUID that is supplied by kong is a 128 but UUID. This has dashes in but is still 128 bits and so can be coerced into the Otel 128 bit number by removing the dashes and parsing as hex.

When sending to your APM, depending on protocol it will send the trace ID in different formats, but the APM should understand this and decode them to the same value. At least that's the theory.

I haven't used kong, but the docs seem to indicate that the otel plugin allows propagation of various formats:
https://docs.konghq.com/hub/kong-inc/opentelemetry/#propagation. Is this something you have configured?

from router.

Hey @BrynCooke, if that is the case, then brilliant! Nothing else to do here, just wait until #5071 is merged and I will report back this issue.

Regarding our kong setup, we have trace id enabled in traces. The format is something I will have to check when the MR gets in and I can test it on a live environment.

from router.