Add a way to enable specific instrumentations rather than rely on disabling

[kamalmarhubi]

Is your feature request related to a problem? We have a monorepo with multiple executables sharing a codebase. This means we have many of the opentelemetry instrumentations installed. However we don't necessarily want all instrumentations on all executables. If sticking with opentelemetry-instrumentation, we would need to add to the OTEL_PYTHON_DISABLED_INSTRUMENTATIONS variable every time someone adds a new instrumentation library. This is tedious and error-prone: we can accidentally end up with an instrumentation enabled on some service that we don't want or need.

Describe the solution you'd like Rather than have to keep adding to the list of OTEL_PYTHON_DISABLED_INSTRUMENTATIONS when running those executables, ideally we can just make the configuration opt-in, and not depend on the ambiently-available instrumentation libraries never changing unexpectedly.

My imagines solution is to add a OTEL_PYTHON_ENABLED_INSTRUMENTATIONS env var with the following semantics:

• the new env var lists instrumentations that are considered; if the env var is not set, all installed instrumentations are considered so that this doesn't affect the current experience for anyone not setting it
• the existing OTEL_PYTHON_DISABLED_INSTRUMENTATIONS prevents the listed instrumentations from being enabled
• it is an error to have a instrumentation in OTEL_PYTHON_ENABLED_INSTRUMENTATIONS that is not installed

Describe alternatives you've considered I've already added a OURCOMPANY_ENABLED_INSTRUMENTATIONS env var that we use to do this. Ideally this could be pushed up into the library.

Additional context Add any other context about the feature request here.

[srikanthccv]

The "auto" instrumentation by design instruments all third-party libraries that can be instrumented. People expect instrumentation to work out of the box when they rely on opentelemetry-instrumentation. Users shouldn't have to know that some ENABLED_INSTRUMENTATIONS must be configured before they see anything. If they are not interested in telemetry from the library, they can disable it. In your case, when you add a library, also think about its telemetry and choose to disable it. I think it's an oxymoron to say "auto" instrumentation and ask to configure ENABLED_INSTRUMENTATIONS.

[pmcollins]

@srikanthccv, it sounds like @kamalmarhubi is suggesting that auto instrumentation will continue to work as it currently does -- that users wouldn't have to explicitly enable anything -- but that in the unlikely event that they do specify any OTEL_PYTHON_ENABLED_INSTRUMENTATIONS, doing so will make auto instrumentation opt-in.

[kamalmarhubi]

@pmcollins correct, it's intentionally backwards compatible for people who don't set the new env var. It doesn't affect the out-of-the-box experience at all, but does allow explicit control for folks who want it.

[srikanthccv]

Wouldn't it be easier to opt out of what you don't want than list everything you want? In my experience, the instrumentations people want to see enabled are generally large; in many cases, everything is enabled. Adding this will confuse users, and I don't know if there is enough interest for this at this point from the rest of the community.

[kamalmarhubi]

@srikanthccv I'm resurrecting this issue as I'm revisiting our opentelemetry initialisation code, and would like to get rid of our home-grown mechanism if possible :-)

Among the languages with configurable zero-code auto-instrumentation, Python is the only one that doesn't let you explicitly enable individual instrumentations. The auto-instrumentation for .NET, Java, and NodeJS all have a way to do this. The ones for Go and PHP have no ability to enable or disable individual instrumentations at all.

In .NET auto-instrumentation, there is a OTEL_DOTNET_AUTO_INSTRUMENTATION_ENABLED top-level env var that defaults to true. You can set this to false, and enable instrumentations individually via per-instrumentation OTEL_DOTNET_AUTO_TRACES_{0}_INSTRUMENTATION_ENABLED env vars. You can also leave the top-level env var's default value, and use the per-instrumentation env vars to disable individual instrumentations.

In the Java auto-instrumentation agent, there is a top-level OTEL_INSTRUMENTATION_COMMON_DEFAULT_ENABLED env var that defaults to true. You can set this to false, and enable instrumentations individually via per-instrumentation OTEL_INSTRUMENTATION_[NAME]_ENABLED env vars. You can also leave the top-level env var's default value, and use the per-instrumentation env vars to disable individual instrumentations.

The NodeJS auto-instrumentation is most similar in setup to the current way of configuring auto-instrumentation for Python: by default all instrumentations are enabled, but you can set OTEL_NODE_ENABLED_INSTRUMENTATIONS to a comma-separated list to only enable specific instrumentations, or you can set OTEL_NODE_DISABLED_INSTRUMENTATIONS to a comma-separated list to keep all instrumentations except the listed ones.

What I suggested is adding the second half of what NodeJS has. I don't know if there are higher level discussions on standardising on an approach more similar to what Go and .NET do, but at this stage I'd just like to have some way to do this.

Would the maintainers accept either a PR adding OTEL_PYTHON_DISABLED_INSTRUMENTATIONS, or one adding per-instrumentation env vars similar to Java and .NET?