add log_level configuration

[codeboten]

This is to support the env variable OTEL_LOG_LEVEL.

Fixes #120

[marcalff]

Related:

• Standardize SDK logging levels opentelemetry-specification#2039

Until the spec defines an enum for log levels, opentelemetry-configuration can only represent a log level as a string, to be interpreted (differently) by each SDK implementation.

[marcalff]

LGTM.

This is the best we can do now, because the spec does not define an enum for log levels.

[jack-berg]

Can we have an enum based on a subset of the SeverityNumber enum defined in the proto repo? https://github.com/open-telemetry/opentelemetry-proto/blob/4f69356d853029975649c3f38b06fc77d77975fc/opentelemetry/proto/logs/v1/logs.proto#L86-L110

[codeboten]

We could, though without a resolution on open-telemetry/opentelemetry-specification#2039, we may be jumping ahead of the spec

[jack-berg]

We don't use the OTEL_LOG_LEVEL property in opentelemetry-java. For internal SDK logging, we use java util logging (or JUL for short), which comes with a default log level already, and has standard options for changing the log level on a per-library basis. For us, introducing an additional option would only muddy the log configuration story for users.

Therefore, I'm not a good judge of this property of its value since to me from the perspective of a java maintainer, it seems like a mistake. I won't approve, but also won't block progress.

[codeboten]

For internal SDK logging, we use java util logging (or JUL for short), which comes with a default log level already, and has standard options for changing the log level on a per-library basis. For us, introducing an additional option would only muddy the log configuration story for users.

I would expect this property to be used in configuring JUL in the java implementation, would that not be the case? Is there an alternative configuration property available to end users through the configuration file?

[jack-berg]

I would expect this property to be used in configuring JUL in the java implementation, would that not be the case? Is there an alternative configuration property available to end users through the configuration file?

I mean we'd have to have a discussion about it in the java SIG but my given that we've gone this long without supporting OTEL_LOG_LEVEL, I believe we'd skip support for this property under the same reasoning.

Is there an alternative configuration property available to end users through the configuration file?

No. Different tools for different things. The logging ecosystem in java is fractured and to complicated to explain here, but essentially users are used to the idea that they configure the logs from their libraries / frameworks in particular way. If we add support for this property, then there's the question of priority - should / can this property override the user's separate log config? A search for OTEL_LOG_LEVEL in opentelemetry-java doesn't indicate that there's been much discussion on this topic, the opinion I'm expressing here is worth revisiting. But its also noteworthy that we're this far into the of opentelemetry-java, and haven't heard much demand for OTEL_LOG_LEVEL.

[codeboten]

A quick search through the OpenTelemetry github org https://github.com/search?q=org%3Aopen-telemetry%20OTEL_LOG_LEVEL&type=code shows that it's used in a few different SIGs, so it probably makes sense to move forward with it.

@brettmc can you review as it looks like PHP is one of the users of this env variable

[brettmc]

can you review as it looks like PHP is one of the users of this env variable

@codeboten sorry I'm late with the review, but the proposed usage would work for PHP's requirements for log level. 👍