Open tracing/ Open Telemetry

[Ralph Goers <ra...@dslextreme.com>]

At work we use the ThreadContextMap in a manner similar to what is shown in Log4j-Audit - We use Filters/Interceptors to inject data into the ThreadContextMap when a request is received/consumed and inject the data as headers on outbound calls or publishing. 

We are now looking at integrating some of that data into OpenTracing/Open Telemetry. It seems like there should be a way to automatically handle this with the ThreadContextMap but for the life of me I cannot figure out how. The ThreadContextMap by itself doesn’t support integration with HTTP/Kafka/AMQP, etc without leveraging what is in Log4j-Audit. 

It somehow feels wrong that we don’t have a way to support this but the solution isn’t obvious to me.

Thoughts?

Ralph

Re: Open tracing/ Open Telemetry

[Matt Sicker <ma...@musigma.org>]

Might be useful to look at how Micrometer handles it (they’re like a Log4j for observability things):
https://micrometer.io/docs/tracing
https://micrometer.io/docs/observation
And this might be more useful for the thread-context question:
https://micrometer.io/docs/contextPropagation


> On Jun 8, 2023, at 5:40 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> 
> At work we use the ThreadContextMap in a manner similar to what is shown in Log4j-Audit - We use Filters/Interceptors to inject data into the ThreadContextMap when a request is received/consumed and inject the data as headers on outbound calls or publishing. 
> 
> We are now looking at integrating some of that data into OpenTracing/Open Telemetry. It seems like there should be a way to automatically handle this with the ThreadContextMap but for the life of me I cannot figure out how. The ThreadContextMap by itself doesn’t support integration with HTTP/Kafka/AMQP, etc without leveraging what is in Log4j-Audit. 
> 
> It somehow feels wrong that we don’t have a way to support this but the solution isn’t obvious to me.
> 
> Thoughts?
> 
> Ralph