Exclude ASP.NET Core Blazor circuit and polling messages from Azure Monitor

Those are not logs, which is why your Logging:OpenTelemetry:LogLevel filters can't touch them. They're spans, so they need a span-level filter.

They come from SignalR. Blazor Server runs its circuit over a SignalR hub, and Microsoft.AspNetCore.Components.Server.ComponentHub is that hub, so every render and every navigation turns into a hub method call with its own activity. From Logging and diagnostics in ASP.NET Core SignalR:

The second bullet is the reason it feels like flooding: "Hub method activities don't have a parent. This means they aren't bundled under the long-running SignalR connection." You can see it in your own screenshot, four separate trace IDs all stamped 6:53:26 AM, because each one is a root operation instead of sitting under a request.

Nobody turned this on deliberately. The ASP.NET Core instrumentation package "registers extra activity sources for SignalR (Microsoft.AspNetCore.SignalR.Server on .NET 9 and later)", per ASP.NET Core metrics.

To drop them, add a filtering processor. The OpenTelemetry .NET SDK documents this directly: a "FilteringProcessor" works by toggling the Activity.Recorded flag.

using System.Diagnostics;
using OpenTelemetry;

public sealed class BlazorCircuitNoiseFilter : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (activity.Source.Name == "Microsoft.AspNetCore.SignalR.Server" &&
            activity.DisplayName.StartsWith(
                "Microsoft.AspNetCore.Components.Server.ComponentHub/",
                StringComparison.Ordinal))
        {
            activity.ActivityTraceFlags &= ~ActivityTraceFlags.Recorded;
        }
    }
}

var builder = WebApplication.CreateBuilder(args);

builder.Services.ConfigureOpenTelemetryTracerProvider((sp, tracing) =>
    tracing.AddProcessor(new BlazorCircuitNoiseFilter()));

builder.Services.AddOpenTelemetry().UseAzureMonitor();

Register it before UseAzureMonitor(). This is the part that catches people out, and both docs are explicit about it. Add and modify OpenTelemetry says "Add the processor shown here before adding Azure Monitor", and the OpenTelemetry docs say the filtering processor "should be registered BEFORE the processor containing the exporter which should be bypassed". Put it after and it runs without doing anything.

I'd match on the hub name rather than filtering the whole source, otherwise you'll lose spans from your own hubs too. And if you're on .NET 10, Blazor registers Microsoft.AspNetCore.Components and Microsoft.AspNetCore.Components.Server.Circuits as well, so add those names to the condition if anything slips through.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.