Allow users a consistent story across languages to disable first party instrumentation for a library

[bogdandrutu]

What are you trying to achieve?

As maintainers/owners of some open source libraries, we were asked to disable our first party instrumentation because the users uses our library in an environment where they also use the DataDog auto-instrumentation (arguably they should detect first party instrumentation and not double instrument) which duplicates instrumentation and confuses users.

Ideally if this is implemented via the Context, we can actually have this implemented in the SdkTracerProvider will just work in all the instrumentations.

What did you expect to see?

A solution that we can implement in Python/Java/Go/JavaScript.

Additional context.

Add any other context about the problem here. If you followed an existing documentation, please share the link to it.

I know of an existing way to do this in Python, see open-telemetry/opentelemetry-python#181

[tsloughter]

Can't this be done by disabling per-scope with Scope Configuration: #3877 ?

Also, the Developer Experience SIG there is a good chance that a feature like Python's "suppress_instrumentation" will be taken up. But those suppress entire call paths and thus would extend beyond a specific instrumentation library.

I think the spec used to include disabling per-scope (instrumentatlibrary at the time) during pre-GA and it was removed. It ended up being stuck in Erlang/Elixir implementation, https://github.com/open-telemetry/opentelemetry-erlang/blob/main/apps/opentelemetry/src/otel_tracer_server.erl#L94-L101. I plan to replace it with Jack's Scope Configuration.

[mtwo]

Triage notes: @trask will follow up

[bogdandrutu]

Can't this be done by disabling per-scope with Scope Configuration: #3877 ?

Thanks @tsloughter, this will help for the isolated case of the whole library.

Also, the Developer Experience SIG there is a good chance that a feature like Python's "suppress_instrumentation" will be taken up. But those suppress entire call paths and thus would extend beyond a specific instrumentation library.

This would be amazing because this + the scope config will cover most of the cases.