The committers listed above are authorized under a signed CLA.

• ✅ login: SHaaD94 / name: Evgeniy Zuikin (6c3bbb0)
• ✅ login: trask / name: Trask Stalnaker (f5a159c, e456382, 87c9cac)

Prefix is also added in

opentelemetry-java-instrumentation/instrumentation/jboss-logmanager/jboss-logmanager-appender-1.1/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/jbosslogmanager/appender/v1_1/LoggingEventMapper.java

Line 131 in c7617dc

key, k -> AttributeKey.stringKey("jboss-logmanager.mdc." + k));

opentelemetry-java-instrumentation/instrumentation/log4j/log4j-appender-2.17/library/src/main/java/io/opentelemetry/instrumentation/log4j/appender/v2_17/internal/LogEventMapper.java

Line 179 in c7617dc

key, k -> AttributeKey.stringKey("log4j.context_data." + k));

opentelemetry-java-instrumentation/instrumentation/log4j/log4j-appender-2.17/library/src/main/java/io/opentelemetry/instrumentation/log4j/appender/v2_17/internal/LogEventMapper.java

Line 184 in c7617dc

key, k -> AttributeKey.stringKey("log4j.map_message." + k));

removed these as well

@laurit @mateuszrzeszutek do you think we should hold this for 2.0?

This is related to: open-telemetry/opentelemetry-java#5880

If we put structured key value pairs in the body as AnyValue, there is no chance of collision with the attributes and the prefix is uneeded.

one concern I have with putting MDC attributes in the body is that they won't be available to attribute-based processors (e.g. in the collector), or searchable in backends in the same way other log attributes are, at least without additional backend work / interpretation of the log bodies

@laurit @mateuszrzeszutek do you think we should hold this for 2.0?

I think it is fine either way. We could put it in 2.0 along with other breaking changes or just outline this as a breaking change in the release notes of the next release.

Do we need a configuration to enable the prefix of MDC?

hi @SHaaD94! we are preparing to release v2.0 soon, can you rebase your PR and check any CI failures? thx

hi @SHaaD94! we are preparing to release v2.0 soon, can you rebase your PR and check any CI failures? thx

Hello @trask. Done

one concern I have with putting MDC attributes in the body is that they won't be available to attribute-based processors (e.g. in the collector), or searchable in backends in the same way other log attributes are, at least without additional backend work / interpretation of the log bodies

@trask sorry for the delay replying. I don't think we should put MDC attributes in the body - I think we should MapMessage / KeyValuePair in the body.

Do you think we should do this and if so, do you think its worthwhile to bundle in with 2.0?

@trask sorry for the delay replying. I don't think we should put MDC attributes in the body - I think we should MapMessage / KeyValuePair in the body.

Sorry for even more delayed reply 😂
I totally agree with that -- I think MDC attributes are more like metadata of the log message, not the actual data of it; and log record attributes seem to be a better place for them than body.

Do you think we should do this and if so, do you think its worthwhile to bundle in with 2.0?

Translating the MapMessage to log record body? Is it strictly necessary for 2.0, or can we introduce that a bit later?

Discussed in SIG. I will push commit to revert the map_message portion in order to avoid churn since we are planning to move map messages to log body in the future.