Feature request: programmatic tracer option to disable Instrumentation Telemetry (DD_INSTRUMENTATION_TELEMETRY_ENABLED)

[skarthikeyan-oss]

Package Name

github.com/DataDog/dd-trace-go/v2/ddtrace/tracer

Package Version(s)

v2.7.2

Describe the feature you'd like

Instrumentation Telemetry can currently only be disabled via the environment variable
DD_INSTRUMENTATION_TELEMETRY_ENABLED=false. There is no programmatic way to disable it from
code (e.g. a tracer.StartOption).

We maintain an internal wrapper library that initializes the tracer for our services and want it
to disable telemetry by default, without requiring every service owner to remember to export
an env var. We tried setting the env var from our wrapper's init() before starting the tracer,
but it does not work — the telemetry "enabled" decision is latched during package
initialization, before any of our code runs.

Please add a tracer start option to control instrumentation telemetry, e.g.:

tracer.Start(
    tracer.WithInstrumentationTelemetry(false), // proposed
)

Why the env var can't be set from code

internal/telemetry.Disabled() reads the env var exactly once, guarded by a sync.Once:

// internal/telemetry/globalclient.go
var (
    telemetryClientEnabled bool
    telemetryEnabledOnce   sync.Once
)

func Disabled() bool {
    telemetryEnabledOnce.Do(func() {
        telemetryClientEnabled = globalinternal.BoolEnv("DD_INSTRUMENTATION_TELEMETRY_ENABLED", true)
    })
    return telemetryClientEnabled == false
}

The sync.Once is first triggered during package-variable initialization of
internal/llmobs, which constructs telemetry metric handles at package scope:

// internal/llmobs/telemetry.go
var (
    spanStartedHandle = telemetry.Count(telemetry.NamespaceMLObs, telemetryMetricSpanStarted, nil)
    userFlushHandle   = telemetry.Count(telemetry.NamespaceMLObs, telemetryMetricUserFlushes, []string{"error:0"})
)

Because Go initializes imported packages (and their package-level vars) before a dependent
package's init() body runs, this Disabled()/sync.Once fires before any consumer init()
can call os.Setenv(...). By the time the env var is set, the value has already been latched to
the default (enabled).

Reproduction / proof

Tiny debug program; two breakpoints under Delve. bp2 is the sync.Once body in
Disabled(); atmain is the first line of main().

> [bp2] internal/telemetry.Disabled.func1() globalclient.go:116
   116:  telemetryClientEnabled = globalinternal.BoolEnv("DD_INSTRUMENTATION_TELEMETRY_ENABLED", true)
   # os.Getenv("DD_INSTRUMENTATION_TELEMETRY_ENABLED") == ""   -> defaults to ENABLED
   # stack: llmobs.init -> runtime.doInit -> runtime.main

2026/.. env at main start: DD_INSTRUMENTATION_TELEMETRY_ENABLED="false"
> [atmain] main.main() main.go
   # the env var IS "false" by the time main() starts, but the sync.Once
   # already latched "enabled" during package init -> telemetry still emitted

Observed order during process startup:

1. internal/llmobs package init constructs telemetry handles → triggers telemetry.Disabled()'s
   sync.Once. Env var is empty → defaults to enabled.
2. Our wrapper library's init() runs and calls os.Setenv("DD_INSTRUMENTATION_TELEMETRY_ENABLED", "false").
   Too late — the once already ran.
3. main() starts. Env var reads "false", but telemetry is already enabled and is emitted.

Exporting DD_INSTRUMENTATION_TELEMETRY_ENABLED=false in the process environment before launch
works correctly (the once reads "false"), which confirms the issue is purely the
init-time read ordering, not the value itself.

Proposed solution

Add a public tracer.StartOption (and/or a field on the tracer config) so telemetry can be
disabled programmatically at tracer initialization, independent of process env:

// proposed API
tracer.Start(
    tracer.WithInstrumentationTelemetry(false),
)

Is your feature request related to a problem?

No response

Describe alternatives you've considered

No response

Additional context

No response

[skarthikeyan-oss]

Hi Team, Can I have an update please?