feat(vertx): inject context to downstream

[squakez]

With this PR we are propagating the traceparent to downstream applications according to the W3C Trace Context specification. I am not sure if there is any best way to achieve that, in case, just guide me through and I'll change the code accordingly.

Closes #15284

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: squakez / name: Pasquale Congiusti (30912cb)

[jaydeluca]

the typical pattern is injecting context using TextMapSetters is something that happens in a client as opposed to server instrumentation

[squakez]

Not an expert on Otel, but this is what I've seen as a way to propagate context [1]. It's also the way we're doing internally in our framework. If there is a better alternative to achieve the same goal, we can certainly go for it.

[1] https://opentelemetry.io/docs/languages/java/api/#contextpropagators

[laurit]

Usually you'd just call Context.current(). Serializing the context to context propagation headers is used for propagating context to external systems.

[squakez]

The problem with Context.current() is the thread consistency. We have a multithreading environment and we cannot be certain that the thread that was executing the Vertx process is the same later used in the downstream process. That is the reason why we do prefer to use the context propagation via header instead.

[laurit]

If you are using threads in a way where context isn't automatically propagated you could capture the value of Context.current() at a point where it is still available and pass it along manually.
Could you elaborate why you wish to add the header based propagation here instead of doing it inside your own application?

[squakez]

Apache Camel is not a simple application. It's a large framework with the integration of many components. We don't know beforehand how the user configure their applications or if even the user is going to include telemetry or not. We found several problem due to the context propagation in async situations, reason why we are adopting the header propagation [1] which seems to fit perfectly into our design. You can consider Camel as a black box, so, we are expecting upstream traces to carry on a traceparent header when this is somehow instrumented or enabled. Camel expects any upstream to carry on that header. And same for the downstream, Camel will add always a traceparent header for any downstream process to be able to relate the trace. I understood that was the correct way to handle distributed tracing.

[1] https://github.com/apache/camel/blob/main/proposals/tracing.adoc#context-propagation

[squakez]

@laurit FYI, I've created a reproducer in the issue linked for this PR [1] if you want to have a look.

[1] #15284 (comment)