OTLP Exporter builder issues

[cijothomas]

Methods like install_batch created unintended side-effects https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-otlp/src/span.rs#L143-L150

1. It sets global providers, which may not be what user has intended.
2. It returns a tracer with instrumentation scope set to "opentelemetry-otlp", which is incorrect as well.

The 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!

[cijothomas]

I used traces as an example - same/similar issue for all signals exist and need a unified fix.

[mattbodd]

I'm interested in taking this on

[NickLarsenNZ]

Adding a permalink (for the link in the description):

opentelemetry-rust/opentelemetry-otlp/src/span.rs

Lines 143 to 150 in d5392dc

	let tracer = provider.versioned_tracer(
	"opentelemetry-otlp",
	Some(env!("CARGO_PKG_VERSION")),
	Some(SCHEMA_URL),
	None,
	);
	let _ = global::set_tracer_provider(provider);
	tracer

[cijothomas]

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.

[TommyCpp]

I will do it for the tracing pipelines if no one else pick it up within next week

[NickLarsenNZ]

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.

[lalitb]

Is the logs one linked anywhere in this issue?

Not linked, but it was removed as part of global cleanups in #1691 .