Open tracing/ Open Telemetry

2023-06-08 Thread Ralph Goers
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

2023-06-08 Thread Matt Sicker
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  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