[
https://issues.apache.org/jira/browse/LOG4J2-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17453458#comment-17453458
]
Ralph Goers commented on LOG4J2-3200:
-------------------------------------
Here is the thing. Opentelemetry provides a Java SDK you are supposed to use to
implement it. They don't really describe in detail how it works and I've never
had an interest to investigate it. My understanding is that it relies on an
agent to intercept http requests and add the trace id.
The methodology described in Log4j-Audit is much simpler. It simply causes the
correlation id to be stored in Log4j's ThreadContext and then passed as an http
header on any REST calls. Downstream services use the Filter to copy the data
in the header into the ThreadContext. The RequestContext is really just the
Log4j ThreadContextMap with fixed fields that you defined.
To answer your questions:
# Log4jServletFilter has access to the HTTP Request so it can get at the
headers and store them in the ThreadContextMap. "Normal" Java code doesn't have
access to the Http Request because it wasn't passed to them. I don't see
anything in the Web Lookup documentation that indicates it has access to the
Http Request nor do I see a reference to web:header.name. The code doesn't
have access to the Http Request so it can't support that.
# As I said, the RequestContext is really just a way to defined fixed keys in
Log4j's ThreadContextMap. Open Telemetry won't be in the RequestContext unless
you put it there. You would define the trace id and span id in the
RequestContext and then use the Filter and Interceptor to propagate them from
one service to another.
# Presumably, if you use the opentracing SDK the only thing you would need to
do to Log4j is whatever the SDK tells you to.
In short, Log4j doesn't directly support opentelemetry. It supports the concept
of distributed tracing but not via opentelemetry.
I know things like Datadog and Dynatrace support open telementry. I've never
used it. Instead I rely on what Log4j-Audit describes for distributed tracing.
FWIW, the RequestContext is actually used for more than that as it can pass
things like a tenant id in a multi-tenant system, the end-users ip address for
audit logging, their locale for I18N support, etc.
> Log4j2 compatibility with Open Telemetry
> ----------------------------------------
>
> Key: LOG4J2-3200
> URL: https://issues.apache.org/jira/browse/LOG4J2-3200
> Project: Log4j 2
> Issue Type: Question
> Components: Filters
> Reporter: Rémi C.
> Priority: Blocker
>
> Hello,
> I am trying to fetch the trace id generated by open telemetry with only
> configuration in log4j2.xml file and web.xml file.
> I created a stack overflow ticket, see :
> [https://stackoverflow.com/questions/70194344/how-to-access-request-header-value-with-log4j2]
>
> Is it possible with the log4j2 lookup to be compatible with open telemetry?
> I tried to use ${web:header.traceId} and it just does not work. I have
> followed the config. So, am I missing something to make it work?
> I saw that even without the web.xml config I added, the ${web:rootDir}
> still works.
> There is almost no information on the internet on how to make it work with
> Open Telemetry so I am asking to the expert here. Open Telemetry is basically
> a field/value that is set in the HTTP request header.
>
> Thank you
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
