Add support for OpenTelemetry Logging

[ppkarwasz]

We should consider adding support for the OpenTelemetry Logging specification to Log4j API 3.x.

This would require:

• creating a new log4j-otel bridge that implements LoggerProvider,
• enhance the Log4j API to help with implementation of log4j-otel. I am mostly concerned about the LogRecordBuilder#setContext method, i.e. a way to programmatically inject context data into a logging event like we do with LogBuilder#withLocation for the location data. We obviously don't expect users to add context data manually in their code, but some instrumentation can do it the same way we inject location with Log4j Transformer Maven plugin.

What do you think?

[jack-berg]

creating a new log4j-otel bridge that implements LoggerProvider,

Are you suggesting a bridge to convert log4j log records to OpenTelemetry log records, or a bridge to convert OpenTelemetry log records into log4j log records? I think only the former should be pursued. The OpenTelemetry log bridge API is not meant to be called by application developer (i.e. its not meant to replace existing log APIs like log4j2, slf4j, JUL, etc). Instead, it exists for the purpose of writing log appenders, which bridge logs recorded in existing log APIs to OpenTelemetry, so that they can be processed / exported in a common way to any trace and metric telemetry.

So while I don't think it makes sense to implement LoggerProvider, I do think it makes sense to use LoggerProvider in an appender. This is exactly what we do in the OpenTelemetry log4j log appender. I think it could be really cool to consider upstreaming this into log4j such that OpenTelemetry is just another appender option in the list from the docs.

[jvz]

We're considering a fresh v3 logging API which the existing v2 API will be updated to extend (which has become fairly bloated over time). Given the similarity between LoggerProvider and LoggerContext, we were looking to see if there was anything to reuse from OpenTelemetry. The point of this API (as was before) is to provide a structured logging API (key differentiator from SLF4J and the original reason v2 began) which works with several different backend SDKs such as the main Log4j Core (maybe we should refer to it as the SDK now), Logback, java.util.logging, or whatever. However, since many programmers don't read the documentation, they are under the false impression that the logging API is tied to the SDK. Structured logging seems to be very similar to the OpenTelemetry concept of signals, so we're trying to figure out how to best combine things. I had pointed out some OpenTelemetry APIs from opentelemetry.io (which are all presented in language-agnostic contexts unlike the GitHub repos you've linked) seemed like something to consider.

While I haven't checked the dependency tree for the SDK or any collectors and such, I'm not sure to what extent you've already accomplished what we're trying to do here, but one of the main things is that we're at the bottom of the dependency stack, and as such, we accomplish a lot without bringing in third party dependencies. On the other hand, various observability libraries I've used in the past download half the internet and tend to break every other month or so (at least prior to OpenTelemetry; since Spring integrated Micrometer, I hope this is less fragile there, but it's a common issue). Similar to #2027, we'd like to do some of this directly rather than having other projects guess at the right place to instrument or extend Log4j since we can make whatever cross-cutting updates are needed to best support things. Perhaps you have some suggestions?

[ppkarwasz]

@jack-berg,

Thank you for the explanation. Apparently I understood the OpenTelemetry Log Bridge API wrong.

We should probably write a log4j-to-otel Log4j API implementation that forwards everything to OpenTelemetry.