Capture unformatted log message as attribute

[philsttr]

Is your feature request related to a problem? Please describe.

Currently, the logging instrumentations (logback, log4j, java-util-logging, jboss-logmanager) do not capture the unformatted log message. They only capture the formatted log message, with all arguments substituted.

For example, say an application has a log line similar to this:

logger.info("My favorite color is: {}", favoriteColor);

And the application calls that log line with various colors. The logging instrumentation would set the log record bodies to:

• My favorite color is: blue
• My favorite color is: red
• My favorite color is: green

This makes it hard for logging backends to identify related messages. For example, say you wanted to create a dashboard for top errors, but only wanted to list one item per pattern, and not one item per unique combination of arguments.

Describe the solution you'd like

I'd like for the OpenTelemetry Java Instrumentation for loggers to optionally be able to capture the unformatted log message as an attribute.

Currently, the log data model does not define a field for the unformatted log message, and the semantic conventions do not define an attribute for the unformatted log message. Therefore, the instrumentation should allow the user to specify the attribute in which to capture the unformatted message.

For example, when using the logback instrumentation via the java agent, the user could specify:

otel.instrumentation.logback-appender.experimental.capture-unformatted-message-attribute=unformatted_message

which configures the logback instrumentation to capture the unformatted message in an attribute named unformatted_message

From the example above, the three events would all have the unformatted_message attribute set to My favorite color is: {}

Ideally this would be implemented across the logback, log4j, java-util-logging, and jboss-logmanager library and agent instrumentations.

Describe alternatives you've considered

No response

Additional context

Might be worth defining a new log.record.unformatted_message attribute semantic convention. Better name suggestions welcome.

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[trask]

hi @philsttr! something similar exists for logback, check out #11865

we would support this pattern being extended to the other logging instrumentations

also see open-telemetry/semantic-conventions#1283

[philsttr]

Ah, interesting. The logback captureArguments option saves the arguments and the template. The name captureArguments implies that it only captures the arguments. And the documentation only mentions that it captures the arguments. It doesn't mention anything about the template, but I do see it in the implementation.

For me, I don't need/want the arguments. I only want the template. So for me, it would be better if this were two different config options.

What do you think about changing the logback captureArguments option to follow its documentation, and only capture the arguments, and then introducing a separate option to capture the template. Perhaps with the attribute name log.record.template as suggested in open-telemetry/semantic-conventions#1283

[philsttr]

Also for consideration... the current option is named captureArguments, but the proposed convention (and currently used attribute name) is log.record.parameters. So there's an name mismatch between parameters and arguments. I'd argue (pun intended) that "arguments" is more appropriate, since the actual values passed are being captured. Not sure what should be done about that though. Change the proposal? Change the attribute used by the current implementation? Change the option name? Leave as-is?

[trask]

can you comment on open-telemetry/semantic-conventions#1283?

let's see if we can get some consensus on the attribute names

I agree it makes sense to have an option that only captures the template and not the args