Support opt-in and opt-out options #84
Description
Component(s)
No response
Is your feature request related to a problem? Please describe.
With the operator, you have specific types of services deployed to a k8s namespace, so it's safe to auto-instrument them all. But we learned from our customers that they deploy all sorts of stuff to a system, including lots of utilities that definitely cannot cope with the agent being added in. We've had customers that for ease of deployment simply defined a global JAVA_TOOL_OPTIONS that always included the agent, and we had to add specific configurable opt-out and opt-in capabilities in the agent startup so that the agent never initialized for various cases.
These are exactly the type of customers that want a one-install auto-instrumentation capability like the injector - but at the same time it won't work for them because of this limitation that it would auto-instrument things that can't cope with being instrumented!
Describe the solution you'd like
I think a similar approach to that suggested in Support multiple agent versions will work nicely! It would work for both opt-in and opt-out whichever the user prefers, eg another configuration file that uses a regex key to point to the appropriate conf file. So eg otelmetainject.conf with contents for opt-out
/no-instrumentation/=
default=/path/otelinject.conf
or for opt-in
/do-instrumentation/=/path/otelinject.conf
default=
where if the process command-line matches the regex key, it uses the corresponding config file, and no file means don't add any agent
Describe alternatives you've considered
I think you would need to define OTEL_INJECT_CONFIG_PATH on a per-process basis (works for both opt-in and opt-out, but is cumbersome)
Additional context
No response
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.