Adding Trace Sources and Meter Names from Configuration

[pbolduc]

It is convenient for all the instrumentation libraries to provide nice helpers such as .AddRedisInstrumentation() or .AddHttpClientInstrumentation() etc. In other cases I may want to provide a list of sources or meters from configuration. The reason for this is you may want to enable or disable certain meters or trace sources differently per environment. Also, you may find your production environment is missing or have too many traces or metrics (you know you can never have enough metrics :-). Having to recompile/create a new runtime image to adjust the list is undesirable.

It would be nice to have something like the following code. I can see there could be more overloads of the configuration extensions. This code could be included in the core dotnet sdk, or I could see another opt in contrib library like OpenTelemetry.Extensions.Configuration

appsettings.Production.json

{
  "OpenTelemetry": {

    "Tracing": {
      "Sources": [
        "MassTransit",
        "Microsoft.AspNetCore.Hosting",
        "Microsoft.AspNetCore.Server.Kestrel",
        "OpenTelemetry.Instrumentation.StackExchangeRedis",
        "ZiggyCreatures.Caching.Fusion",
        "ZiggyCreatures.Caching.Fusion.Backplane",
        "ZiggyCreatures.Caching.Fusion.Distributed",
        "ZiggyCreatures.Caching.Fusion.Memory"
      ]
    },

    "Metrics": {
      "Meters": [
        "MassTransit",
        "ZiggyCreatures.Caching.Fusion",
        "ZiggyCreatures.Caching.Fusion.Backplane",
        "ZiggyCreatures.Caching.Fusion.Distributed",
        "ZiggyCreatures.Caching.Fusion.Memory"
      ]
    }
  }
}

and loading the sources like:

using Microsoft.Extensions.Configuration;
using OpenTelemetry.Trace;

namespace OpenTelemetry.Metrics;

public static class OpenTelemetryExtensions
{
    public static void AddMetersFromConfiguration(this MeterProviderBuilder builder, IConfiguration configuration)
    {
        var options = GetOptions(configuration);

        foreach (var meter in options.Metrics.Meters)
        {
            builder.AddMeter(meter);
        }
    }

    public static void AddSourcesFromConfiguration(this TracerProviderBuilder builder, IConfiguration configuration)
    {
        var options = GetOptions(configuration);

        foreach (var source in options.Tracing.Sources)
        {
            builder.AddSource(source);
        }
    }

    private static OpenTelemetryOptions GetOptions(IConfiguration configuration)
    {
        var options = new OpenTelemetryOptions();
        var section = configuration.GetSection("OpenTelemetry");

        section.Bind(options);

        return options;
    }
}

public class OpenTelemetryOptions
{
    public OpenTelemetryTracingOptions Tracing { get; } = new OpenTelemetryTracingOptions();
    public OpenTelemetryMetricsOptions Metrics { get; } = new OpenTelemetryMetricsOptions();
}

public class OpenTelemetryMetricsOptions
{
    public List<string> Meters { get; } = new List<string>();
}

public class OpenTelemetryTracingOptions
{
    /// <summary>
    /// The sources to trace.
    /// </summary>
    public List<string> Sources { get; } = new List<string>();
}

Sample usage:

builder.Services.AddOpenTelemetry().WithMetrics(options =>
{
    options.AddMetersFromConfiguration(builder.Configuration);
});

builder.Services.AddOpenTelemetry().WithTracing(options =>
{
    options.AddSourcesFromConfiguration(builder.Configuration);
});

[martinjt]

This will work for some, but not others, which makes it problematic.

For Redis for instance, you need access to the IConnectionMultiplexer, for Rabbit, you need to inject/configure baggage handlers. Enabling tracers/ActivitySources via config could be nice, but it's not universal. That doesn't mean it won't be done.

There is an Otel SIG ongoing about how this might work to enable standardisation of these.

Right now, you can enable Metrics this way (since there is nothing that needs configuring), it's part of the core of how .NET IMetricsBuilder works.