otel_log_level (common debug) proposal #139
Conversation
ghost
requested review from
There was a problem hiding this comment.
I think that this PR would only add noise as I think that it is obvious that if something is defined in OTel spec then we should support it.
The only addition is that the spec only mentions info and here we are having INFO, DEBUG, TRACE. Maybe we should rather make a PR to the OTel spec with value proposals.
|
@MrAlias Already created an issue: open-telemetry/opentelemetry-specification#2039 |
It is obvious, but for non-OTel (yes, we have non-OTel components) it is not. Hence this PR. |
|
If the component is non-OTel then maybe we should name it Moreover, it would help the reviewers if you elaborate on why this change is needed. |
| @@ -135,7 +135,11 @@ beyond the OpenTelemetry specification exist. | |||
| - `OTEL_TRACES_EXPORTER` | |||
| - Non-RUM distribution MUST default to `otlp` over gRPC with an endpoint of `localhost:4317` | |||
| - Non-RUM distribution MUST offer `jaeger-thrift-splunk` that defaults to `http://127.0.0.1:9080/v1/trace` | |||
|
|
|||
| - `OTEL_LOG_LEVEL` | |||
| - Distribution SHOULD support `DEBUG` setting. With this value all relevant troubleshooting data should be logged. | |||
There was a problem hiding this comment.
AFAIK supporting this would involve hacking in most of the SDKs. I would rather make a hack to convert debug to DEBUG if a component needs it as it seems more OTel compliant.
There was a problem hiding this comment.
There was a problem hiding this comment.
Yeah, we need to wait for the values to be finalized in the spec. Then it will be a no-brainer ;)
This was my idea. But @flands believes that it will be better to support "OTEL" debug var in other (non-OTel) libs. |
| - Distribution MAY support additional levels: | ||
| - `INFO` - coarser-grained informational events than the `DEBUG`. | ||
| - `TRACE` - finer-grained informational events than the `DEBUG`. |
There was a problem hiding this comment.
If we're going to use OTEL_LOG_LEVEL (which is a good idea, since it's stable in the otel spec) I believe we should wait for the OTel spec issues to get resolved before deciding on anything here.
There was a problem hiding this comment.
Good point. Let's wait for open-telemetry/opentelemetry-specification#2039
There was a problem hiding this comment.
I don't want to introduce log levels here that'll end up not being included in the otel spec...
I wasn't aware of that - What kind of non-OTel components are we expecting(or are already) to follow the GDI spec? |
Currently - the metrics extension (based on SFx metrics) which is bundled with the Splunk OTel Lambda Layer. It has currently different config for logging which IMO is confusing for end-users. Hence this request. |
ghost
closed this
No description provided.