move module enabled to "agent" in declarative config

[zeitlinger]

See #15777 (comment)

Use Cases

Use cases to disable a module:

• agent: problems inherent in using bytecode instrumentation
• native instrumentation: comment from @trask I'm not sure that's an important use case outside of the Java agent (which needs it due to it being zero code, and due to the problems inherent in using bytecode instrumentation)
• spring starter: does not have bytecode, but startup time is important - and users expect to be able to disable modules

What else can be done:

• Tracer can be disabled in declarative config: https://github.com/open-telemetry/opentelemetry-configuration/blob/main/snippets/ExperimentalTracerConfigurator_kitchen_sink.yaml
• same for logger: https://github.com/open-telemetry/opentelemetry-configuration/blob/main/snippets/ExperimentalLoggerConfigurator_kitchen_sink.yaml
• and meter: https://github.com/open-telemetry/opentelemetry-configuration/blob/main/snippets/ExperimentalMeterConfigurator_kitchen_sink.yaml

Design

Note:

• this issue includes the task to move all "javaagent" properties to the distribution node (Declarative configuration: move .instrumentation.java.agent node to .distribution.java_agent #15800)

Agent

distribution:
  javaagent:
    instrumentation:
      default_enabled: true
      disabled:
        - dropwizard
      enabled: # used if default_enabled=false
        - dropwizard

Spring Starter

same, but use spring_starter as distro name.

Native Instrumentation

It might also be good to give native instrumentations the ability to no-op quickly, but they can already tracer/instrument/logger isEnabled and we want to see if that is sufficient.

[trask]

Proposal:

move these:

• otel.instrumentation.common.default-enabled
• otel.instrumentation.xyz.enabled

out of

.instrumentation/development.java.common

and into

• .instrumentation/development.java.agent, and
• .instrumentation/development.java.spring_starter

nodes

(if native instrumentations want to be as no-op as possible, they can check tracer/instrument/logger isEnabled)

[zeitlinger]

@trask @jack-berg please review the design

[trask]

• aligns with https://github.com/open-telemetry/opentelemetry-configuration/blob/main/snippets/ExperimentalTracerConfigurator_kitchen_sink.yaml - except we use "enabled" instead of "disabled"

this will hopefully be changed to enabled in declarative configuration: open-telemetry/opentelemetry-specification#4823

I'd suggest first PR just move existing .instrumentation.java.agent node to .distribution.javaagent

Then follow-up PR to move .instrumentation.java.common.default-enabled and .instrumentation.java.xyz.enabled to .distribution.javaagent

[trask]

I'm not sure we need the complex nesting, since other instrumentation config should be handled under .instrumentation node, and this is only for enabling/disabling whole instrumentations, e.g. maybe something like would work

distribution:
  javaagent:
    instrumentation:
      default_enabled: true
      disabled:
        - dropwizard
      enabled: # used if default_enabled=false
        - dropwizard

[zeitlinger]

I'm not sure we need the complex nesting, since other instrumentation config should be handled under .instrumentation node, and this is only for enabling/disabling whole instrumentations, e.g. maybe something like would work

distribution:
  javaagent:
    instrumentation:
      default_enabled: true
      disabled:
        - dropwizard
      enabled: # used if default_enabled=false
        - dropwizard

if we want to go down that route we can take https://github.com/open-telemetry/opentelemetry-configuration/blob/987c78b3b4c1c1f63133fa31a36aba8502da63cc/schema/common.yaml#L2 - no need for a default_enabled in that case

[trask]

if we want to go down that route we can take https://github.com/open-telemetry/opentelemetry-configuration/blob/987c78b3b4c1c1f63133fa31a36aba8502da63cc/schema/common.yaml#L2 - no need for a default_enabled in that case

I think this is designed for cases where the default is nothing, so not sure how to model default_enabled=false for our use case?

[zeitlinger]

if we want to go down that route we can take https://github.com/open-telemetry/opentelemetry-configuration/blob/987c78b3b4c1c1f63133fa31a36aba8502da63cc/schema/common.yaml#L2 - no need for a default_enabled in that case

I think this is designed for cases where the default is nothing, so not sure how to model default_enabled=false for our use case?

You're right - doesn't make any sense - let's go with your proposal