{{% config_option name="otel.javaagent.enabled" %}}

Set the value to false to disable the agent entirely.

{{% /config_option %}}

You can disable all default auto instrumentation and selectively re-enable individual instrumentation. This may be desirable to reduce startup overhead or to have more control of which instrumentation is applied.

{{% config_option name="otel.instrumentation.common.default-enabled" %}} Set to false to disable all instrumentation in the agent. {{% /config_option %}}

{{% config_option name="otel.instrumentation.[name].enabled" %}} Set to true to enable each desired instrumentation individually. {{% /config_option %}}

{{% alert title="Note" color="warning" %}} Some instrumentation relies on other instrumentation to function properly. When selectively enabling instrumentation, be sure to enable the transitive dependencies too. Determining this dependency relationship is left as an exercise to the user. This is considered advanced usage and is not recommended for most users. {{% /alert %}}

You can suppress all auto instrumentations but have support for manual instrumentation with @WithSpan and normal API interactions by using -Dotel.instrumentation.common.default-enabled=false -Dotel.instrumentation.opentelemetry-api.enabled=true -Dotel.instrumentation.opentelemetry-instrumentation-annotations.enabled=true

You can suppress agent instrumentation of specific libraries.

{{% config_option name="otel.instrumentation.[name].enabled" %}} Set to false to suppress agent instrumentation of specific libraries, where [name] is the corresponding instrumentation name: {{% /config_option %}}

Note: When using environment variables, dashes (-) should be converted to underscores (_). For example, to suppress traces from akka-actor library, set OTEL_INSTRUMENTATION_AKKA_ACTOR_ENABLED to false.

Some instrumentations (e.g. Spring Web MVC instrumentation) produce SpanKind.Internal spans to capture the controller and/or view execution. These spans can be suppressed using the configuration settings below, without suppressing the entire instrumentation which would also disable the instrumentation's capturing of http.route and associated span name on the parent SpanKind.Server span.

{{% config_option name="otel.instrumentation.common.experimental.controller-telemetry.enabled" default=false %}} Set to true to enable controller telemetry. {{% /config_option %}}

{{% config_option name="otel.instrumentation.common.experimental.view-telemetry.enabled" default=false %}} Set to true to enable view telemetry. {{% /config_option %}}

Some libraries that this agent instruments in turn use lower-level libraries, that are also instrumented. This would normally result in nested spans containing duplicate telemetry data. For example:

• Spans produced by the Reactor Netty HTTP client instrumentation would have duplicate HTTP client spans produced by the Netty instrumentation;
• Dynamo DB spans produced by the AWS SDK instrumentation would have children HTTP client spans produced by its internal HTTP client library (which is also instrumented);
• Spans produced by the Tomcat instrumentation would have duplicate HTTP server spans produced by the generic Servlet API instrumentation.

The Java agent prevents these situations by detecting and suppressing nested spans that duplicate telemetry data. The suppression behavior can be configured using the following configuration option:

{{% config_option name="otel.instrumentation.experimental.span-suppression-strategy" %}}

The Java agent span suppression strategy. The following 3 strategies are supported:

• semconv: The agent will suppress duplicate semantic conventions. This is the default behavior of the Java agent.
• span-kind: The agent will suppress spans with the same kind (except INTERNAL).
• none: The agent will not suppress anything at all. We do not recommend using this option for anything other than debug purposes, as it generates lots of duplicate telemetry data.

{{% /config_option %}}

For example, suppose we instrument a database client which internally uses the Reactor Netty HTTP client; which in turn uses Netty.

Using the default semconv suppression strategy would result in 2 nested CLIENT spans:

• CLIENT span with database client semantic attributes emitted by the database client instrumentation;
• CLIENT span with HTTP client semantic attributes emitted by the Reactor Netty instrumentation.

The Netty instrumentation would be suppressed, as it duplicates the Reactor Netty HTTP client instrumentation.

Using the suppression strategy span-kind would result in just one span:

• CLIENT span with database client semantic attributes emitted by the database client instrumentation.

Both Reactor Netty and Netty instrumentations would be suppressed, as they also emit CLIENT spans.

Finally, using the suppression strategy none would result in 3 spans:

• CLIENT span with database client semantic attributes emitted by the database client instrumentation;
• CLIENT span with HTTP client semantic attributes emitted by the Reactor Netty instrumentation;
• CLIENT span with HTTP client semantic attributes emitted by the Netty instrumentation.