Global accessor for LogEmitterProvider

[jack-berg]

Should there be a global accessor for LogEmitterProvider? In java (discussed here) we think the answer is no because the global accessor is reserved for API components (i.e. MeterProvider, TracerProvider) and there is no log API.

Instead, each appender we publish has a global setter for configuring the LogEmitterProvder. For example, here is the setter for the log4j appender.

[wallezhang]

Why doesn't the appender use auto configured LogEmitterProvder in GlobalOpenTelemetry directly? I think the global setter in appender is used for configure LogEmitterProvider manually.

[jack-berg]

@wallezhang GlobalOpenTelemetry doesn't have accessors for SdkLogEmitterProvider because GlobalOpenTelemetry is part of the API package, and there is no otel logging API. SdkLogEmitterProvider is part of the logging SDK.

[wallezhang]

@wallezhang GlobalOpenTelemetry doesn't have accessors for SdkLogEmitterProvider because GlobalOpenTelemetry is part of the API package, and there is no otel logging API. SdkLogEmitterProvider is part of the logging SDK.

Yeah, I know, however, I think it will be very strange to use this way. For example, I initialized the SDK by agent, I still need to manually initialize a SdkLogEmitterProvider while there is already an initialized SdkLogEmitterProvider in GlobalOpenTelemetry, and then set it through log global setter before it can be used in log.

[anuraaga]

@wallezhang You should be using slf4j if you need to write log messages, not the logs SDK. If you have a strong case needing the OpenTelemetry logging functionality, could you add a comment to https://github.com/open-telemetry/opentelemetry-specification/issues/2234 with details of your use case? Currently, the answer is that your use case is not supported by OpenTelemetry so we would need some big discussion in the specification repo to make it supported.

the functions and methods callable from this SDK package are intended to be used by Logging Libraries only and are NOT intended to be used by the end user and will NOT be exposed in the OpenTelemetry API package.

[wallezhang]

@anuraaga Yes, of course I will use slf4j to print log in application. But I think the appender provided in the instrumentation library is a little complicated to use. When I use java agent to initialize whole SDK, I need to inject a SdkLogEmitterProvider into log global setter to make the configured appender effective.

Maybe we can simplify usage by injecting the autoconfigured SdkLogEmitterProvider to the appender.

[anuraaga]

Oh if you're trying to use the javaagent to add an appender to logback or log4j to send OpenTelemetry logs, that injection should indeed be happening automatically here

https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/963b5cc087bcc546fe777b2d4df6cbfca8d72d04/javaagent-tooling/src/main/java/io/opentelemetry/javaagent/tooling/OpenTelemetryInstaller.java#L58

Are you seeing the appender not get initialized fully automatically when using the javaagent? If so we can file an issue in the java instrumentation repo for that.

[wallezhang]

Thanks for reply. I'll try it first.

[pranavmarla]

Should there be a global accessor for LogEmitterProvider? In java (discussed here) we think the answer is no because the global accessor is reserved for API components (i.e. MeterProvider, TracerProvider) and there is no log API.

Instead, each appender we publish has a global setter for configuring the LogEmitterProvder. For example, here is the setter for the log4j appender.

FYI, the following link from the original post is now dead:

For example, here is the setter for the log4j appender.

So here is an updated permalink: setter for the log4j appender

[jack-berg]

This was resolved in #2676. There's now explicit text stating:

Normally, the LoggerProvider is expected to be accessed from a central place. Thus, the API SHOULD provide a way to set/register and access a global default LoggerProvider.