[feature request] Add configuration extensions for ActivitySource and Meter names

[paulomorgado]

Component

OpenTelemetry.Extensions

Is your feature request related to a problem?

Applications using the OpenTelemetry .NET SDK must register custom tracing sources and metric meters programmatically:

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddSource("MyCompany.Orders")
        .AddSource("Npgsql"))
    .WithMetrics(metrics => metrics
        .AddMeter("MyCompany.Orders"));

In applications where instrumentation is selected at deployment time, the source and meter names need to come from IConfiguration. Every application currently has to implement the same binding code:

var tracingSources = builder.Configuration
    .GetSection("OpenTelemetry:Tracing:Sources")
    .Get<string[]>() ?? [];

var metricMeters = builder.Configuration
    .GetSection("OpenTelemetry:Metrics:Meters")
    .Get<string[]>() ?? [];

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing.AddSource(tracingSources))
    .WithMetrics(metrics => metrics.AddMeter(metricMeters));

This is small but repeated infrastructure code. Implementations can also differ in how they handle missing sections, invalid values, configuration-provider compatibility, and diagnostics.

The zero-code instrumentation project offers OTEL_DOTNET_AUTO_TRACES_ADDITIONAL_SOURCES and OTEL_DOTNET_AUTO_METRICS_ADDITIONAL_SOURCES, but those settings do not configure applications using the OpenTelemetry SDK directly.

What is the expected behavior?

Add configuration-oriented extensions to OpenTelemetry.Extensions for registering ActivitySource and Meter names.

A possible API is:

namespace OpenTelemetry.Trace;

public static class TracerProviderBuilderConfigurationExtensions
{
    public static TracerProviderBuilder AddSourcesFromConfiguration(
        this TracerProviderBuilder builder,
        IConfigurationSection section);
}

namespace OpenTelemetry.Metrics;

public static class MeterProviderBuilderConfigurationExtensions
{
    public static MeterProviderBuilder AddMetersFromConfiguration(
        this MeterProviderBuilder builder,
        IConfigurationSection section);
}

The methods would read string-array configuration sections and delegate to the existing AddSource(params string[]) and AddMeter(params string[]) APIs.

Example configuration:

{
  "OpenTelemetry": {
    "Tracing": {
      "Sources": [
        "MyCompany.Orders",
        "Npgsql"
      ]
    },
    "Metrics": {
      "Meters": [
        "MyCompany.Orders"
      ]
    }
  }
}

Example usage:

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing.AddSourcesFromConfiguration(
        builder.Configuration.GetSection("OpenTelemetry:Tracing:Sources")))
    .WithMetrics(metrics => metrics.AddMetersFromConfiguration(
        builder.Configuration.GetSection("OpenTelemetry:Metrics:Meters")));

Because the caller supplies an IConfigurationSection, the extensions would not impose a fixed configuration hierarchy. Values could come from any standard configuration provider, including appsettings.json, environment variables, command-line arguments, Azure App Configuration, or a secrets provider.

Suggested behavior:

• A missing or empty section is a no-op.
• Null, empty, or whitespace-only entries fail during provider construction with an error that identifies the configuration path.
• Names are passed unchanged to the existing SDK APIs, retaining their matching and wildcard behavior.
• Duplicate handling remains consistent with the existing SDK APIs.
• Configuration is read when the provider is constructed.
• Configuration reload does not dynamically replace subscriptions, because TracerProvider and MeterProvider subscriptions are established at startup.
• XML documentation should state the expected array shape and startup-only behavior.

For example, environment-variable configuration would continue to work through normal .NET configuration mapping:

OpenTelemetry__Tracing__Sources__0=MyCompany.Orders
OpenTelemetry__Tracing__Sources__1=Npgsql
OpenTelemetry__Metrics__Meters__0=MyCompany.Orders

Which alternative solutions or features have you considered?

1. Bind the arrays in every application

   tracing.AddSource(
       configuration.GetSection("OpenTelemetry:Tracing:Sources")
           .Get<string[]>() ?? []);

   This works, but requires repeated infrastructure code and each application must define its own validation and missing-section behavior.

2. Create an application-specific extension

   Applications can implement AddSourcesFromConfiguration and AddMetersFromConfiguration themselves. This duplicates the same behavior across services and organizations.

3. Use zero-code auto-instrumentation environment variables

   OTEL_DOTNET_AUTO_TRACES_ADDITIONAL_SOURCES and OTEL_DOTNET_AUTO_METRICS_ADDITIONAL_SOURCES provide similar functionality, but only for .NET automatic instrumentation. They do not configure an explicitly constructed OpenTelemetry SDK pipeline.

4. Use OpenTelemetry declarative configuration

   OpenTelemetry.Configuration.Declarative is currently experimental and does not yet apply tracing-provider or metrics-provider configuration. Applications still need to call AddSource and AddMeter in code.

5. Use a third-party configuration package

   Some third-party packages provide complete configuration-driven OpenTelemetry setup, but adopting an opinionated telemetry distribution is excessive when an application only needs to register source and meter names.

Additional context

This appears to fit OpenTelemetry.Extensions because it is a .NET-specific convenience around IConfiguration, rather than a new cross-language OpenTelemetry capability.

Passing an explicit IConfigurationSection also avoids defining configuration keys that could conflict with future OpenTelemetry declarative-configuration conventions.

The proposed names are intended to distinguish these startup configuration helpers from the existing AddSource and AddMeter methods, but alternative naming consistent with repository conventions would be welcome.

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.}

[martincostello]

I believe this already exists in .NET itself - I haven't tried it myself, I've been meaning to but haven't gotten around to it yet. I'll probably try now once I've finished writing this comment...

Microsoft.Extensions.Diagnostics added functionality for configuring meters from configuration in .NET 10, and similar functionality for activity sources was added for .NET 11 (dotnet/runtime#100317).

If those do the job, then I don't think we'd want to duplicate it.

[martincostello]

I tried this out in an application of my own targeting .NET 11 rc.1, but it doesn't work (martincostello/costellobot#3878).

While I can configure meters and activity sources, they don't get applied onto anything, so meters and traces aren't emitted.

I think we'd need to build functionality into the OpenTelemetry SDK (like in the hosting extensions package, where the DI glue already lives) to provide a bridge between the two systems so that OpenTelemetry can leverage the configuration setup in Microsoft.Extensions.Diagnostics.