Blazor - rendering metrics and tracing #61609

pavelsavara · 2025-04-22T10:32:13Z

Blazor metrics

new meter Microsoft.AspNetCore.Components
aspnetcore.components.navigation - Total number of route changes.
aspnetcore.components.event_handler - Duration of processing browser event including business logic.
new meter Microsoft.AspNetCore.Components.Lifecycle
aspnetcore.components.update_parameters - Duration of processing component parameters including business logic.
aspnetcore.components.render_batch - Duration of rendering batch including browser round-trip.
meter Microsoft.AspNetCore.Components.Server.Circuits
aspnetcore.components.circuit.active - Number of active circuits in memory.
aspnetcore.components.circuit.connected - Number of circuits connected to client.
aspnetcore.components.circuit.duration - Duration of circuit lifetime and their total count.

Blazor activity tracing

new activity source Microsoft.AspNetCore.Components
Microsoft.AspNetCore.Components.CircuitStart: Circuit {circuitId}
- tags: aspnetcore.components.circuit.id
- links: HTTP activity
Microsoft.AspNetCore.Components.RouteChange: Route {route} -> {componentType}
- tags: aspnetcore.components.circuit.id, aspnetcore.components.type, aspnetcore.components.route
- links: HTTP trace, circuit trace
Microsoft.AspNetCore.Components.HandleEvent: Event {attributeName} -> {componentType}.{methodName}
- tags: aspnetcore.components.circuit.id, aspnetcore.components.type, aspnetcore.components.method, aspnetcore.components.attribute.name, error.type
- links: HTTP trace, circuit trace, router trace

builder.Services.ConfigureOpenTelemetryMeterProvider(meterProvider =>
{
    meterProvider.AddMeter("Microsoft.AspNetCore.Components");
    meterProvider.AddMeter("Microsoft.AspNetCore.Components.Server.Circuits");
});
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

Out of scope

WASM

Contributes to #53613
Contributes to #29846
Feedback for #61516
Related open-telemetry/semantic-conventions#2235

# Conflicts: # src/Components/Components/src/PublicAPI.Unshipped.txt

- add tracing

JamesNK · 2025-04-24T23:30:15Z

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 · 2025-04-25T18:46:19Z

Having many low level metrics could cause performance issues.

I removed few and kept only 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 · 2025-04-25T19:24:16Z

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.

pavelsavara · 2025-04-28T07:30:30Z

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:

I'm capturing Activity.Current.Context in ComponentHub constructor, which happens before any Activity changes in the SignalR layer, and so I'm able to capture HTTP Activity. Capture works, I test the Name and I get the TraceId just fine.

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.

This is it, thank you @BrennanConroy !

pavelsavara · 2025-04-28T07:38:45Z

It's also topic to discuss for long running activities on Blazor.

current circuit - this is object in memory, with SignalR connection. Could be hours or even days long.
current route - this is more logical than physical. But it makes sense to link click event activities to the current route

We have 2 way how to deal with them I think

keep them open for the whole long duration
- should we install them back to Activity.Current on next HTTP/SignalR request for child Activity sake ?
- Should we use parent relationship instead of link ? I understood the feedback in 29846 to mean that long running parent makes bad UX in the dashboard.
close them soon - at the end of the current event/click/navigation
- this makes them immediately visible in dashboard/OTEL and linkable
- but we don't capture the true duration other sub-spans: disconnect, reconnect, close

Right now I have short+links implementation.

I guess developers use OTEL mostly in production and so even the long running traces would be recorded already.

But maybe developers also use it in inner dev loop ? In which case it would be great to have "trace preview" for thing that started but not stopped yet. To not get confused the same way as I did.

- cleanup

samsp-msft · 2025-04-30T16:10:29Z

Sam: Is circuitId useful for DisplayName of Circuit activity? What else we could display there instead. Could we have IP address ?

My mind set - if a customer is having an issue with your site, and calls IT to complain - how do they match the traces to the user? Is there somewhere that ID gets displayed to them?

If we don't stick in that data (which is a good from a being secure by default position) is there a hook-point we can document before the activity is finished that the customer can access the activity and add their extra tags to it? As the circuit is created as an instantaneous activity, it may not be on the stack for many calls to user code where they can access it.

pavelsavara · 2025-04-30T16:35:51Z

I think this problem of mapping traces to users on hotline is not specific to Blazor.

I'm linking the HTTP Activity/trace that created the circuit, so if there is more tags on the HTTP trace, they could use that (after the session and the long running HTTP/WS connection is finished).

Sometimes there is authenticated user in the HTTP context, but I think it's probably not good for use to expose any PII.

If the app developer wanted to add more tags, I believe that they could capture Activity.Current and add something.

Maybe the app developer could also add "show my circuitID" into application settings menu and the IT call center could ask them to click it. The circuitID is random number and it's not a secret from security perspective.

samsp-msft · 2025-04-30T17:32:34Z

If the app developer wanted to add more tags, I believe that they could capture Activity.Current and add something.

The activity is created in CircuitFactory at line 127 and is stopped at line 173. Is there any user code executed between these points where the activity would be active, so they can retrieve it and add tags. Once its stopped, AFAIK its too late to add anything to it.

samsp-msft

Some naming suggestions.

For sessions, I wonder if when log messages are fired, is the activity context going to be the session activity, and if not is there a way to force it to be? @noahfalk this is an issue with essentially zero length spans - you might want to force log messages to be parented to it but something else is the activity at that point?

src/Components/Components/src/ComponentsActivitySource.cs

src/Components/Components/src/ComponentsMetrics.cs

samsp-msft · 2025-04-30T23:17:02Z

src/Components/Components/src/ComponentsMetrics.cs

+            {
+                { "component.type", componentType ?? "unknown" },
+                { "component.method", methodName ?? "unknown" },
+                { "attribute.name", attributeName ?? "unknown" }


I understand why this is based on the attribute, but its really also the event name. would that make more sense as "event"?

This refers to onclick in the example below. Attribute makes it easier for me personally but I don't have strong preference. It's attributeName thru Blazor internals.

@danroth27 do you prefer "event" or something else ?

<button class="btn btn-primary" @onclick="Buy" @focus="OnFocus">Buy</button>

samsp-msft · 2025-04-30T23:19:14Z

src/Components/Components/src/ComponentsMetrics.cs

+
+            var tags = new TagList
+            {
+                { "component.type", componentType ?? "unknown" },


code.class.name? to match https://github.com/open-telemetry/semantic-conventions/blob/main/docs/attributes-registry/code.md

We don't really have code reference, as in file name and line number.

My initial thought is that the thing being refered to was the Blazor component abstraction in which case component.type and component.method made sense to me. The fact that code.class.name isn't currently defined also nudges me in that direction. If we did want to use code.* attributes instead this feels like another spot where OTel semconv feedback could be helpful.

src/Components/Components/src/ComponentsMetrics.cs

src/Shared/Metrics/MetricsConstants.cs

noahfalk · 2025-05-01T23:00:02Z

This goes back to my #61609 (comment).
That activity is relatively short lived at the moment, compared to whole life-time of the circuit. We can change that with consequences for inner dev loop.

OnCircuit - is representing logical circuit (duration), but at the moment, we stop it earlier.
OnRoute - is representing logical route/page in the app. Logicaly it should be active until you navigate elsewhere, but right now we stop it early. It links to circuit (when Blazor interactive).
OnEvent - in Blazor interactive, something was clicked. It typically happens inside of specific route and circuit which are linked.

Right now, the short circuit and route activities mostly serve as something that click event activities could link to. For the context.

Thanks, that helps a bunch on understanding where things are at now. A couple thoughts:

In the question how to handle long-lived activities I think there is a 3rd option which is not to produce the activity at all. Instead of an event linking to the activity the only reference would be the circuit.id tag or route.id tag.
Using links and ~0-length activities as a grouping/linking mechanism feels like a novel use of distributed tracing telemetry that many tools may not visualize in a helpful way. Have you tried looking at any of the telemetry in Azure Monitor's portal? As I recall Azure Monitor's viewer is quite aggressive at following links transitively in both the backwards and forwards directions. I'm suspicious that if you try to visualize any event AzureMonitor is going to wind up showing you every route and event in the entire circuit superimposed on a single very cluttered timeline.
If we keep Circuit and Route I agree a name like CircuitStart or RouteStart/RouteChanged might be more readily understood. For Event perhaps we drop the 'On' and just name it 'Event' or 'HandleEvent'?

For sessions, I wonder if when log messages are fired, is the activity context going to be the session activity, and if not is there a way to force it to be? @noahfalk this is an issue with essentially zero length spans - you might want to force log messages to be parented to it but something else is the activity at that point?

Activity.Current can be set at any time, but it can't be set to an Activity that is already stopped. If you did want to produce the set of all log messages that occurred within a given circuit I think the best options would be one of:

In the telemetry viewer, query for all activities where circuit.id tag = X, then merge all logs linked to those activities. (This requires tools to support a table JOIN across logs and distributed traces which probably isn't universally supported)
Add circuit.id as another field in the log messages and query for it directly. circuit.id could either be an explicit field in select log messages, or it could be added via enrichment. Once the field is there querying for all logs where circuit.id=X would return the desired logs.

Co-authored-by: Sam Spencer <[email protected]>

pavelsavara · 2025-05-06T13:32:31Z

All, I created open-telemetry/semantic-conventions#2235 in order to validate and document the new metrics in OTEL community.

As a result I updated all tags in this PR with prefix aspnetcore.components

pavelsavara · 2025-05-07T10:07:34Z

@lmolkova's feedback on the other PR is

merge duration and exception metrics into single histogram metric. Our HTTP _requestDuration already does that too. I will do it.

"event" means something specific in otel. But also something in the browser and in Blazor. Suggestion to rename aspnetcore.components.event to aspnetcore.components.operation or aspnetcore.components.call.

Perhaps we should think about it as event handler ? aspnetcore.components.event_handler
circuits.active_circuits -> circuit.active
rendering.batch -> render_batch
update_parameters -> parameter_set or parameter_binding
rename aspnetcore.components metrics prefix to -> aspnetcore.component because of otel pluralization rules.
This would create mismatch with C# existing namespace. I prefer C# namespace because that is a existing namespace already. I will keep it as it is, unless somebody here convinces me otherwise.

- rename aspnetcore.components.circuit to aspnetcore.components.circuits - rename circuits.active_circuits to circuit.active and connected_circuits to circuit.connected - rename aspnetcore.components.event.duration to aspnetcore.components.event_handler and include exceptions - rename aspnetcore.components.update_parameters.duration to aspnetcore.components.update_parameters and include exceptions - rename aspnetcore.components.rendering.batch.duration to aspnetcore.components.render_diff and include exceptions

pavelsavara · 2025-05-07T15:12:57Z

@lmolkova I pushed changes based on your feedback.

The remaining issues are

update_parameters instrument name - I don't have strong opinion
aspnetcore.components namespace vs aspnetcore.component namespace.
Your proposal has one benefit, which is that aspnetcore.component.type tag sounds much better than aspnetcore.components.type for a specific class name. The downside is that we would not match C# namespace.

I will discuss it with @javiercn and come to some conclusion.

javiercn · 2025-05-15T11:01:24Z

src/Components/Server/src/Circuits/RemoteRenderer.cs

@@ -369,7 +369,7 @@ private async Task CaptureAsyncExceptions(Task task)
        }
    }

-    private static partial class Log
+    private static new partial class Log


Is this new really needed here?

It's a warning now after I added the project reference.
It is hiding the parent logger.

A) If we want to use the parent logger, I can delete this one.
B) or I can #pragma the warning

javiercn · 2025-05-15T11:02:43Z

src/Components/Components/src/RegisterRenderingMetricsServiceCollectionExtensions.cs

+        // do not register IConfigureOptions<StartupValidatorOptions> multiple times
+        if (!IsMeterFactoryRegistered(services))
+        {
+            services.AddMetrics();
+        }


Is this check to avoid calling services.AddMetrics() more than once? Is there a failure in that situation?

javiercn · 2025-05-15T11:08:05Z

src/Components/Server/src/Circuits/CircuitHost.cs

@@ -105,7 +108,7 @@ public CircuitHost(

    // InitializeAsync is used in a fire-and-forget context, so it's responsible for its own
    // error handling.
-    public Task InitializeAsync(ProtectedPrerenderComponentApplicationStore store, CancellationToken cancellationToken)
+    public Task InitializeAsync(ProtectedPrerenderComponentApplicationStore store, ActivityContext httpContext, CancellationToken cancellationToken)


Can we name this activityContext? httpContext has a very well-defined meaning across the codebase and it set the expectation that it's an HttpContext instance, which this is not.

javiercn · 2025-05-15T11:12:50Z

src/Components/Server/src/Circuits/CircuitHost.cs

@@ -51,6 +52,7 @@ public CircuitHost(
        RemoteNavigationManager navigationManager,
        CircuitHandler[] circuitHandlers,
        CircuitMetrics? circuitMetrics,
+        ComponentsActivitySource? componentsActivitySource,


The activity source and the metrics shouldn't be nullable, they should be the same as RemoteJsRuntime and other parameters.

We unconditionally register them https://github.com/dotnet/aspnetcore/pull/61609/files#diff-e82512017622b574554e1a1519f2bb3bbb1d8957e5346b3a4cbeb0f10e368c79R64 and

https://github.com/dotnet/aspnetcore/pull/61609/files#diff-9e461d4480403d04ed6d5e6c31c44261fe8d5926969ab338dd910564ea211396R79-R80

We should throw an exception if they aren't being provided similarly to how we do for other services.

javiercn · 2025-05-15T12:02:32Z

src/Components/Components/src/ComponentsActivitySource.cs

+    public static ActivityContext CaptureHttpContext()
+    {
+        var parentActivity = Activity.Current;
+        if (parentActivity is not null && parentActivity.OperationName == "Microsoft.AspNetCore.Hosting.HttpRequestIn" && parentActivity.Recorded)
+        {
+            return parentActivity.Context;
+        }
+        return default;
+    }


Layering wise this shouldn't go here.

Microsoft.AspNetCore.Components shoudn't have a dependency on Microsoft.AspNetCore.Hosting

Please be more specific, what do you want to see instead ?

Are you trying to get the activity of the current request here? There is a feature in the features collection for doing that: https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.features.ihttpactivityfeature.activity?view=aspnetcore-9.0

Can I get that from DI without passing HttpContext thru all SignalR layers ? Or from some TLS ?

It comes from HttpContext. It's in the features collection.

javiercn · 2025-05-15T12:03:34Z

src/Components/Components/src/ComponentsActivitySource.cs

+    public Activity? StartCircuitActivity(string circuitId, ActivityContext httpContext)
+    {
+        _circuitId = circuitId;
+
+        var activity = ActivitySource.CreateActivity(OnCircuitName, ActivityKind.Internal, parentId: null, null, null);
+        if (activity is not null)
+        {
+            if (activity.IsAllDataRequested)
+            {
+                if (_circuitId != null)
+                {
+                    activity.SetTag("aspnetcore.components.circuit.id", _circuitId);
+                }
+                if (httpContext != default)
+                {
+                    activity.AddLink(new ActivityLink(httpContext));
+                }
+            }
+            activity.DisplayName = $"Circuit {circuitId ?? ""}";
+            activity.Start();
+            _circuitContext = activity.Context;
+        }
+        return activity;
+    }
+
+    public void FailCircuitActivity(Activity? activity, Exception ex)
+    {
+        _circuitContext = default;
+        if (activity != null && !activity.IsStopped)
+        {
+            activity.SetTag("error.type", ex.GetType().FullName);
+            activity.SetStatus(ActivityStatusCode.Error);
+            activity.Stop();
+        }
+    }
+
+    public Activity? StartRouteActivity(string componentType, string route)
+    {
+        if (_httpContext == default)
+        {
+            _httpContext = CaptureHttpContext();
+        }
+
+        var activity = ActivitySource.CreateActivity(OnRouteName, ActivityKind.Internal, parentId: null, null, null);
+        if (activity is not null)
+        {
+            if (activity.IsAllDataRequested)
+            {
+                if (_circuitId != null)
+                {
+                    activity.SetTag("aspnetcore.components.circuit.id", _circuitId);
+                }
+                if (componentType != null)
+                {
+                    activity.SetTag("aspnetcore.components.type", componentType);
+                }
+                if (route != null)
+                {
+                    activity.SetTag("aspnetcore.components.route", route);
+                }
+                if (_httpContext != default)
+                {
+                    activity.AddLink(new ActivityLink(_httpContext));
+                }
+                if (_circuitContext != default)
+                {
+                    activity.AddLink(new ActivityLink(_circuitContext));
+                }
+            }
+
+            activity.DisplayName = $"Route {route ?? "[unknown path]"} -> {componentType ?? "[unknown component]"}";
+            activity.Start();
+            _routeContext = activity.Context;
+        }
+        return activity;
+    }


This should go on the Server assembly.

If we move it to different class/instance, we would not be able to use _circuitId and _circuitContext. And we would have to create lot of semi-public interfaces to pass that info between those classes. Are you sure it's worth it ?

Isn't the CircuitId on a parent activity? (like start circuit or something like that)

All the _httpContext, _circuitContext on that event is at the wrong level of abstraction. I don't know if it can be set on the parent activity and flowed into this one, but the route activity should not know about _circuitContext or _httpContext.

To put it in a different way, this method/class should not be responsible for resolving the parent activity to link to. That should be provided somehow. We might need public API for that.

We don't want to keep adding to this list when/if we add new render modes. For example, I imagine WebView migth also want to track its own parent activity and it would require us to add it here.

javiercn · 2025-05-15T12:05:06Z

src/Components/Components/src/ComponentsActivitySource.cs

+    public Activity? StartEventActivity(string? componentType, string? methodName, string? attributeName)
+    {
+        var activity = ActivitySource.CreateActivity(OnEventName, ActivityKind.Internal, parentId: null, null, null);
+        if (activity is not null)
+        {
+            if (activity.IsAllDataRequested)
+            {
+                if (_circuitId != null)
+                {
+                    activity.SetTag("aspnetcore.components.circuit.id", _circuitId);
+                }
+                if (componentType != null)
+                {
+                    activity.SetTag("aspnetcore.components.type", componentType);
+                }
+                if (methodName != null)
+                {
+                    activity.SetTag("aspnetcore.components.method", methodName);
+                }
+                if (attributeName != null)
+                {
+                    activity.SetTag("aspnetcore.components.attribute.name", attributeName);
+                }
+                if (_httpContext != default)
+                {
+                    activity.AddLink(new ActivityLink(_httpContext));
+                }
+                if (_circuitContext != default)
+                {
+                    activity.AddLink(new ActivityLink(_circuitContext));
+                }
+                if (_routeContext != default)
+                {
+                    activity.AddLink(new ActivityLink(_routeContext));
+                }
+            }
+
+            activity.DisplayName = $"Event {attributeName ?? "[unknown attribute]"} -> {componentType ?? "[unknown component]"}.{methodName ?? "[unknown method]"}";
+            activity.Start();
+        }
+        return activity;
+    }
+
+    public static void FailEventActivity(Activity? activity, Exception ex)
+    {
+        if (activity != null && !activity.IsStopped)
+        {
+            activity.SetTag("error.type", ex.GetType().FullName);
+            activity.SetStatus(ActivityStatusCode.Error);
+            activity.Stop();
+        }
+    }
+
+    public static async Task CaptureEventStopAsync(Task task, Activity? activity)
+    {
+        try
+        {
+            await task;
+            activity?.Stop();
+        }
+        catch (Exception ex)
+        {
+            FailEventActivity(activity, ex);
+        }
+    }
+}


This probably needs to go into a different class ComponentEventActivitySource (or any other name, RendererEventMetrics or something like that)

javiercn · 2025-05-15T12:12:39Z

src/Components/Components/src/RenderTree/Renderer.cs

@@ -770,6 +813,7 @@ private void ProcessRenderQueue()

        _isBatchInProgress = true;
        var updateDisplayTask = Task.CompletedTask;
+        var batchStartTimestamp = ComponentMetrics != null && ComponentMetrics.IsBatchEnabled ? Stopwatch.GetTimestamp() : 0;


Don't remember the exact syntax, but you can write it like below

Suggested change

var batchStartTimestamp = ComponentMetrics != null && ComponentMetrics.IsBatchEnabled ? Stopwatch.GetTimestamp() : 0;

var batchStartTimestamp = ComponentMetrics is { IsBatchEnabled: true } ? Stopwatch.GetTimestamp() : 0;

javiercn · 2025-05-15T12:16:20Z

src/Components/Components/src/Rendering/ComponentState.cs

+
+        if (_renderer.ComponentMetrics != null && _renderer.ComponentMetrics.IsParametersEnabled)
+        {
+            _componentTypeName = component.GetType().FullName;


Is this perf related or "convenience" related.

Adding a field to ComponentState is not great, since this increments the cost of each component that gets created (which your app can have thousands of).

This is for perf. Because we need that type _componentTypeName on all parameter updates on each component instance. (when this metric is enabled)

pavelsavara added the area-blazor Includes: Blazor, Razor Components label Apr 22, 2025

pavelsavara added this to the 10.0-preview5 milestone Apr 22, 2025

pavelsavara self-assigned this Apr 22, 2025

pavelsavara mentioned this pull request Apr 22, 2025

Blazor - rendering metrics #61516

Merged

This was referenced Apr 22, 2025

slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883

Open

The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008

Open

rebase

cebb68e

pavelsavara force-pushed the blazor_metrics_feedback branch from 328a584 to cebb68e Compare April 23, 2025 18:01

pavelsavara added 3 commits April 23, 2025 20:06

Merge branch 'main' into blazor_metrics_feedback

6664645

# Conflicts: # src/Components/Components/src/PublicAPI.Unshipped.txt

more

0bcd459

- remove FeatureSwitchDefinition for now

2557f08

- add tracing

pavelsavara changed the title ~~Blazor - rendering metrics - feedback~~ Blazor - rendering metrics and tracing Apr 24, 2025

whitespace

4c75495

pavelsavara requested review from noahfalk and JamesNK April 24, 2025 11:10

build-analysis bot mentioned this pull request Apr 24, 2025

Known Build Error: error : Cannot create a file when that file already exists. #61178

Open

pavelsavara added 3 commits April 24, 2025 18:35

navigation draft

0f3d48a

cleanup

cf15c8d

cleanup

550f633

build-analysis bot mentioned this pull request Apr 24, 2025

System.OperationCanceledException : The operation was canceled. dotnet/dnceng#5278

Open

3 tasks

pavelsavara added 2 commits April 25, 2025 19:40

more

9ab8a84

IsAllDataRequested

0a4d488

- ComponentsActivitySourceTest

cf2ab99

- cleanup

pavelsavara requested a review from samsp-msft April 28, 2025 08:21

pavelsavara marked this pull request as ready for review April 28, 2025 09:51

samsp-msft reviewed Apr 30, 2025

View reviewed changes

pavelsavara and others added 6 commits May 2, 2025 10:37

Update src/Components/Components/src/ComponentsActivitySource.cs

2ae95e0

Co-authored-by: Sam Spencer <[email protected]>

Update src/Components/Components/src/ComponentsActivitySource.cs

b9331d9

Co-authored-by: Sam Spencer <[email protected]>

Update src/Components/Components/src/ComponentsActivitySource.cs

96f1d6a

Co-authored-by: Sam Spencer <[email protected]>

feedback

1c61f50

ActivityKind.Internal

bda2aec

aspnetcore.components prefix for tags

84dbfd2

pavelsavara mentioned this pull request May 6, 2025

Add new Blazor metrics for Net10 open-telemetry/semantic-conventions#2235

Draft

3 tasks

pavelsavara mentioned this pull request May 7, 2025

Add Metrics for Blazor #53613

Open

2 tasks

pavelsavara added 3 commits May 7, 2025 16:08

Event -> HandleEvent trace rename

2ea50aa

remove aspnetcore.components.circuit.count

971f484

Improve descriptions

db97013

javiercn reviewed May 15, 2025

View reviewed changes

Merge branch 'main' into blazor_metrics_feedback

09986be

	var batchStartTimestamp = ComponentMetrics != null && ComponentMetrics.IsBatchEnabled ? Stopwatch.GetTimestamp() : 0;
	var batchStartTimestamp = ComponentMetrics is { IsBatchEnabled: true } ? Stopwatch.GetTimestamp() : 0;

Blazor - rendering metrics and tracing #61609

Are you sure you want to change the base?

Blazor - rendering metrics and tracing #61609

Conversation

pavelsavara commented Apr 22, 2025 • edited Loading

Blazor metrics

Blazor activity tracing

Feedback

JamesNK commented Apr 24, 2025

pavelsavara commented Apr 25, 2025 • edited Loading

BrennanConroy commented Apr 25, 2025

pavelsavara commented Apr 28, 2025

pavelsavara commented Apr 28, 2025 • edited Loading

samsp-msft commented Apr 30, 2025

pavelsavara commented Apr 30, 2025 • edited Loading

samsp-msft commented Apr 30, 2025

samsp-msft left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

noahfalk commented May 1, 2025

pavelsavara commented May 6, 2025

pavelsavara commented May 7, 2025 • edited Loading

pavelsavara commented May 7, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

javiercn May 15, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

javiercn May 15, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JamesNK May 15, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pavelsavara commented Apr 22, 2025 •

edited

Loading

pavelsavara commented Apr 25, 2025 •

edited

Loading

pavelsavara commented Apr 28, 2025 •

edited

Loading

pavelsavara commented Apr 30, 2025 •

edited

Loading

pavelsavara commented May 7, 2025 •

edited

Loading

javiercn May 15, 2025 •

edited

Loading

javiercn May 15, 2025 •

edited

Loading

JamesNK May 15, 2025 •

edited

Loading