Blazor - rendering metrics and tracing

[pavelsavara]

Better rendering metrics

aspnetcore.components.rendering.batch.duration - Duration of rendering batch.
aspnetcore.components.rendering.batch.exception - Total number of exceptions during batch rendering.
aspnetcore.components.event.duration - Duration of processing browser event asynchronously.
aspnetcore.components.parameters.duration - Duration of processing component parameters asynchronously.
aspnetcore.components.navigation.count - Total number of route changes.

builder.Services.ConfigureOpenTelemetryMeterProvider(meterProvider =>
{
    meterProvider.AddMeter("Microsoft.AspNetCore.Components");
    meterProvider.AddMeter("Microsoft.AspNetCore.Components.Server.Circuits");
});

Blazor activity tracing

• new activity source Microsoft.AspNetCore.Components.Rendering

builder.Services.ConfigureOpenTelemetryTracerProvider(tracerProvider =>
{
    tracerProvider.AddSource("Microsoft.AspNetCore.Components");
    //tracerProvider.AddSource("Microsoft.AspNetCore.SignalR.Server");
});

Feedback

• always expect the IMeterFactory to be available in DI
• make buckets different size per feedback
• optimize work with tags
• make metrics in seconds per feedback
• unit test delay feedback

TODO - Metrics need to be documented at https://learn.microsoft.com/en-us/aspnet/core/log-mon/metrics/built-in

Contributes to #53613
Contributes to #29846
Feedback for #61516

[JamesNK]

You're adding a lot of metrics here. I think you should do some performance testing. There is performance overhead of metrics - they require some synronization when incrementing counters and recording values.

Having many low level metrics could cause performance issues.

[pavelsavara]

Having many low level metrics could cause performance issues.

I removed few and left on the most useful ones.
The only aspnetcore.components.parameters.duration is per Blazor component.
It's async and executes customer's business logic.
If they have thousands of them they are in trouble anyway. And this will help them to figure it out.
The rest of them are per request, which should be OK.

I have 2 remaining issues

• on metrics/duration histogram I'm unable to see any time bigger than 5 in dashboard. I assume it is the 0.005s bucket. Even if I have added 1s delay and validated stopwatch said 1.1s TotalSeconds. I think there is some problem with aggregation or display ? Or maybe all the other fast examples are drowning this one ?
• on tracing/activities I would like to link HTTP activity from the place where SignalR is creating the Blazor circuit. So I capture it's Activity.Current.Context and use it later to AddLink() on my activity. In some cases it leads to the HTTP activity, but in may cases the HTTP activity is not in the dashboard at all. I'm thinking it could be sampling. I would like to skip the link if I know that the HTTP activity was not selected for sampling. But HTTP activity always (on dev machine without pressure) have .Recorded true and sometimes is missing on the dashboard anyway.

I would appreciate hints, many thanks! @noahfalk @JamesNK

[BrennanConroy]

• I would like to link HTTP activity from the place where SignalR is creating the Blazor circuit. So I capture it's Activity.Current.Context and use it later to AddLink() on my activity.

I don't know how Blazor circuits are created, but if it's from a Hub method then Activity.Current won't be the HTTP activity. We hop off the HTTP activity on purpose in SignalR:

aspnetcore/src/SignalR/server/Core/src/Internal/DefaultHubDispatcher.cs

Lines 398 to 403 in 9f2b088

	// Hub invocation gets its parent from a remote source. Clear any current activity and restore it later.
	var previousActivity = Activity.Current;
	if (previousActivity != null)
	{
	Activity.Current = null;
	}

• in may cases the HTTP activity is not in the dashboard at all

Is that because the HTTP request is still running? I don't think activites show up in the dashboard until they're stopped, and if you're using SignalR you're likely using a websocket request which is long running.