Capture log4j2 context data (mdc) attributes - #4959
Conversation
|
I would add the same allow-list param as request headers, or otherwise a deny-list if it seems more appropriate for log context. allow-list seems to fit well IMO with the expectation that context data only does something if it is actually referenced in e.g. log4j.xml pattern string. I have seen log context be used for very non-log stuff such as database sharding keys (worse is putting the actual user ID in and generating the key at query-time which I've also seen...). |
|
I think capturing all MDC attributes is the nicest default (once spec'd), under the assumption that most people put things into logging MDC because they want those things tied to their logs. Definitely agree with supporting people who put weird things into logging MDC as well though, whether its via allow-list or deny-list. I'd like to get a sense if others agree with the (eventual) default above, as that will help influence decision on allow-list vs deny-list. |
|
Switched to allow-list, see updated description. |
* Capture log4j2 context data (mdc) attributes * Spotless * Remove system.out.println * Switch to allow-list * Spotless
Addsotel.instrumentation.log4j-appender.experimental-log-attributesproperty that enables capturing log4j2 context data as attributes.Adds
otel.instrumentation.log4j-appender.experimental.capture-context-data-attributesproperty which is an allow-list of context data attributes to capture. It accepts a lone*to mean capture all context data attributes.Context data attributes
xyzis captured aslog4j.context_data.xyz, taking some inspiration fromhttp.request.header.xyz.