Expose active instrumented integrations (Parity with Ruby)

[stevenboyd]

Package Name

No response

Package Version(s)

No response

Describe the feature you'd like

In the Ruby Datadog library (dd-trace-rb), developers have access to configuration.instrumented_integrations, which returns a list of all currently active integrations. This is incredibly useful for internal health checks, debugging observability setups, and ensuring that all expected integrations (e.g., net/http, database/sql, gin) are correctly initialized in different deployment environments.

Currently, dd-trace-go tracks this exact information under the hood for internal telemetry (via the unexported integrations map[string]integrationConfig field in the core config struct). However, because this map is unexported and there are no getter functions, this information is entirely walled off from developers.

If we want to verify which integrations are active at runtime, we have to manually track our initialization logic in our own application configuration structs, which creates boilerplate and is prone to human error.

I would like to propose adding a public getter function to the tracer package that returns a slice of strings containing the names of all currently registered and active integrations.

Since the tracer registers integrations dynamically as they are initialized (e.g., when calling sqltrace.Register), this function would just need to safely read the keys from the internal integrations map.

Example implementation idea:

// Inside ddtrace/tracer/tracer.go

// ActiveIntegrations returns a list of all currently registered Datadog integrations.
func ActiveIntegrations() []string {
	// Acquire read lock on the internal config/tracer state
	// ...
	
	var list []string
	for name := range activeConfig.integrations {
		list = append(list, name)
	}
	return list
}

Is your feature request related to a problem?

No response

Describe alternatives you've considered

The current workaround is manually tracking a boolean or string array in our own application's configuration struct every time we call a Datadog wrapper function (like httptrace.WrapClient). This requires wrapping initialization logic and maintaining duplicate state that the tracer is already tracking internally.

Additional context

No response