Skip to content

Conversation

@philsttr
Copy link
Contributor

@philsttr philsttr commented Nov 21, 2025

Partially implements #15119. Only for logback.

Added a new captureTemplate option to the logback OpenTelemetryAppender. Default is false.
The new option captures the unformatted log message template in the log.body.template log event attribute proposed in open-telemetry/semantic-conventions#1283.

For example:

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

will result in the log.body.template attribute being set to My favorite color is: {}

Enable in the library by configuring the OpenTelemetryAppender with <captureTemplate>true</captureTemplate>.
Enable in the javaagent by setting otel.instrumentation.logback-appender.experimental.capture-template=true.

The existing captureArguments option previously enabled both capturing the template and arguments. However, it was only documented to capture the arguments. Now captureArguments only enables capturing arguments (not the message template). This is a backwards incompatible change to an experimental config option. Users currently setting captureArguments=true would now need to set both captureArguments=true and captureTemplate=true to maintain the previous behavior.

This PR only implements this change for logback (not log4j, jboss-logmanager, or java-util-logging). Others could be done in future PRs.

@philsttr philsttr requested a review from a team as a code owner November 21, 2025 18:06
@github-actions github-actions bot added the test native This label can be applied to PRs to trigger them to run native tests label Nov 21, 2025
Added a new `captureTemplate` option to the logback `OpenTelemetryAppender`.  Default is false.
The new option captures the unformatted log message template in the `log.body.template` log event attribute.

Enable in the library by configuring the `OpenTelemetryAppender` with `<captureTemplate>true</captureTemplate>`.
Enable in the javaagent by setting `otel.instrumentation.logback-appender.experimental.capture-template=true`.

The existing `captureArguments` option previously enabled both capturing the template and arguments.
Now `captureArguments` only enables capturing arguments (not the message template).
This is a backwards incompatible change to an experimental config option.
Users currently setting `captureArguments=true` would now need to set both `captureArguments=true` and `captureTemplate=true` to maintain previous behavior.
@philsttr philsttr force-pushed the gh-15119-log-message-template branch from d14ed35 to 07ef9f9 Compare November 21, 2025 18:24
@philsttr
Copy link
Contributor Author

failing tests seem unrelated to changes in this PR

@zeitlinger
Copy link
Member

proposed in open-telemetry/semantic-conventions#1283.

this is an issue - can you create a PR in sem-conv?

@philsttr
Copy link
Contributor Author

Hallo @zeitlinger

To clarify, the logback instrumentation already populates the log.body.template attribute (and the log.body.parameters attribute). This PR changes the configuration option that controls when the log.body.template attribute gets populated.

I can submit a PR for http://github.com/open-telemetry/semantic-conventions/issues/1283, but I feel that is a separate, but related, issue. In other words, I don't think this PR should depend on the new sem-conv PR, since the attributes are currently in use.

@zeitlinger
Copy link
Member

I don't think this PR should depend on the new sem-conv PR, since the attributes are currently in use.

agreed

@philsttr
Copy link
Contributor Author

philsttr commented Nov 24, 2025

When captureTemplate=true, I'm debating whether the log.body.template should
A) be captured even if no arguments are provided (meaning the message is not really a template, but the full message)
OR
B) only be captured if arguments are provided (thus, indicating that the message is actually a template)

Currently, the PR implements A, but I think I'm leaning toward B now, to reduce log volume.

If I change the implementation to B, then captureTemplate=true + captureArguments=true is essentially the same as the existing captureArguments=true behavior.

Anybody have any thoughts?

@cyrille-leclerc
Copy link
Member

Capturing the logline template & arguments, even when no argument is used, provides the great benefit of enabling log analytics tools to immediately provide log trend analytics without having to parse the logline through CPU & memory intensive log pattern extraction algorithms.

I'm not aware of existing log analytics solution that today leverages log.body.template and log.record.parameters but it's very compelling and should be straightforward to support in log trend analytics.

@philsttr
Copy link
Contributor Author

Capturing the logline template & arguments, even when no argument is used, provides the great benefit of enabling log analytics tools to immediately provide log trend analytics without having to parse the logline through CPU & memory intensive log pattern extraction algorithms.

I think this can be done with both option A or B that i mentioned earlier. For option B, if a log event has no log.event.parameters and the therefore no log.body.template, then the log analytics tools could look at the log body for that event, since in this case its value would be the same as log.body.template if it were written.

@philsttr
Copy link
Contributor Author

philsttr commented Nov 25, 2025

I've updated the implementation to option B.

This reduces log data volume, makes it easier for users to revert to previous behavior, and still enables usage of the log.body.template by log analyzers when available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

test native This label can be applied to PRs to trigger them to run native tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants