Open cijothomas opened 7 months ago
I used traces as an example - same/similar issue for all signals exist and need a unified fix.
I'm interested in taking this on
Adding a permalink (for the link in the description): https://github.com/open-telemetry/opentelemetry-rust/blob/d5392dc1df13b51553577a51d736eac9b29e7125/opentelemetry-otlp/src/span.rs#L143-L150
Both logs, and metrics have completed this cleanup. Neither returns a Logger/Meter, nor set a Global Provider. Tracing is still needing to be fixed to make it consistent with the rest.
I will do it for the tracing pipelines if no one else pick it up within next week
Both logs, and metrics have completed this cleanup. Neither returns a Logger/Meter, nor set a Global Provider. Tracing is still needing to be fixed to make it consistent with the rest.
Is the logs one linked anywhere in this issue? I didn't see it, but am on mobile and maybe missing the obvious.
Is the logs one linked anywhere in this issue?
Not linked, but it was removed as part of global cleanups in #1691 .
Is the logs one linked anywhere in this issue?
Not linked, but it was removed as part of global cleanups in #1691 .
@NickLarsenNZ The logging should not affect end users.. It is only going to affect authors of bridges/appenders.. Curious if you are writing one?
I can work on this if this still needs help.
@ThomsonTan Will see if this is something he can take.
Methods like
install_batch
created unintended side-effects https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-otlp/src/span.rs#L143-L150The builder methods used in OTLP to setup the pipeline must be revisited to ensure that there are no accidental side effects like above. Also, returning tracer with hardcoded name is defeating the purpose of instrumentation scope, as all tracers will have same scope (and that too incorrect one). This is particularly hard when used with
tracer-opentelemetry
, as it'll result in traces which all have same scope!