Configuring when not using UseAzureMonitor()

[christophwille]

We are not using builder.Services.AddOpenTelemetry().UseAzureMonitor(); but the following approach:

            builder.Services.AddOpenTelemetry()
                .ConfigureResource(r =>
                {
                    ....
                })
                .WithTracing(tracerProviderBuilder =>  
                    ....
                    tracerProviderBuilder.AddAzureMonitorTraceExporter();

(Reason: based on flags, we also sometimes - esp. locally - send to AddOtlpExporter();)

Should we tack on it at the very end or what is recommended / expected way in such a configuration scenario? (I will admit that UseAzureMonitor as convenient as it might be is slightly a headache when you export to multiple places)

[christophwille]

My current take:

            var otelBuilder = builder.Services.AddOpenTelemetry()
                .ConfigureResource(r =>
                {
                    ....
                })
                .WithTracing(tracerProviderBuilder =>  
                    ....
                    tracerProviderBuilder.AddAzureMonitorTraceExporter();

             if (useAzureMonitor) otelBuilder.UseProfiler();

[christophwille]

So question basically boils down to - if I do not call UseAzureMonitor() at all, is calling UseProfiler() enough or will it miss stuff that would have been configured by UseAzureMonitor()?

[xiaomi7732]

@christophwille Thanks for the feedback.

As of today, the part that we rely on is in OpenTelemetry for .NET. In theory, you should be fine (of course, connection string is still needed for profiler to work).
If you want to, send us a copy of the trace file once you have it, and we can help double check that is the case.

That said, this is actually an interesting scenario that you are using more than just 1 exporter for different parts.

We probably should have some sort of probe in the bootstrap to making sure the necessary services are registered.

[christophwille]

That said, this is actually an interesting scenario that you are using more than just 1 exporter for different parts.

Examples of things we do:

• AddOtlpExporter() for using Aspire Dashboard locally
• Registering various sources (AddSource() calls)
• Using .SetSampler(new AlwaysOnSampler()) via flag for local devex or tracing absolutely everything in prod
• Modify how EF traces stuff

A slightly outdated version (PoC) of some of this can be found at https://github.com/christophwille/OTel-de-Wille/blob/main/aspnet-aspiredashboard/WebApplicationBuilderExtensions.cs

[xiaomi7732]

Hey @christophwille, how about something like this?

builder.Services.AddOpenTelemetry().ConfigureResource(resource => resource.AddService(serviceName))
    .WithTracing(tracerProviderBuilder =>
    {
        tracerProviderBuilder.AddAspNetCoreInstrumentation()
            .AddAzureMonitorTraceExporter() 
            .UseProfiler();                                         // Enable profiler
    });

[christophwille]

Actually, we now built two code paths - one for standard OTel, one for UseAzureMonitor.

https://github.com/Azure/azure-sdk-for-net/tree/main/sdk/monitor/Azure.Monitor.OpenTelemetry.AspNetCore

builder.Services.ConfigureOpenTelemetryTracerProvider((builder) =>

is where we call methods that are used in both code paths.

builder.Services.Configure<AspNetCoreTraceInstrumentationOptions>(options =>
{
    options.RecordException = true;
    options.Filter = (httpContext) =>
    {
        // only collect telemetry about HTTP GET requests
        return HttpMethods.IsGet(httpContext.Request.Method);
    };
});

That got us the rest of the way. It is ugly, but at least we got away without duplication.