Auto-instrumentation for Blazor
robbiedhickey opened this issue · comments
Are you requesting automatic instrumentation for a framework or library? Please describe.
- Framework or library name : ASP.NET Core Blazor
- Library type: web framework
- Library version: .NET 5-8
Is your feature request related to a problem? Please describe.
We have several internal applications written in Blazor and it is not immediately obvious the best way to manually instrument these due to the long-lived web socket requests.
Describe the solution you'd like
Would love for auto-instrumentation to hook into NavigationManager events and create resources based on the Location, perhaps.
Describe alternatives you've considered
I have tried instrumenting the NavigationManager myself but ultimately the UX is sub-optimal as all spans exist in a single long-lived _blazor request per session.
Additional context
Interested in hearing different thoughts on approaches to this problem.
Hi @robbiedhickey. Thanks for the request, this is something we've looked into, but it hasn't been prioritized yet. The difficulty is the lack of hooks provided in the Blazor runtime, and it also wasn't entirely clear to me what we would want to instrument. I was looking at instrumenting the rendering of components, but I'm not sure that's particularly useful, plus it doesn't actually work that well and would have performance implications.
I don't remember if we considered hooking NavigationManager, but that seems like a reasonable compromise to me, analogous to the spans we receive when rendering statically I guess. The long web-socket request span is a know issue unfortunately that would need addressing first.
To confirm, I assume you're using a Blazor Server app? The new .NET 8 static rendering approach works fine with our existing instrumentation, and client-side will likely never work with insturmentation, so I assume so, just wanted to clarify :)
@andrewlock Thanks for the insight into your teams' discussions, I was running into similar issues identifying good extension points and deciding on what instrumentation would provide value. NavigationManager events seemed like the closest proxy to what we are getting out of other APM integrations.
We are indeed using Blazor Server and are currently on .NET 7, but have a .NET 8 migration prioritized in the backlog that we'll be tackling soon. I'm not totally up to speed on the new render modes but my suspicion is Static wouldn't be an option without quite a bit of refactoring. It's definitely an interesting consideration though.
We pivoted a bit and have now managed to get most of the monitoring/alerts we need through the RUM integration. This approach has limitations but seems to be working okay so far.
Thanks for the info @robbiedhickey! I agree that Static is unlikely to be able to be easily retrofit anywhere (and I have doubts about how realistic the Auto render mode will be for most people).
FWIW, I spotted this comment about adding Activity support to SignalR and Blazor Server in the .NET 9 time frame, so I strongly recommend keeping an eye on that and requesting anything that you think would be useful there :) Anything they put into activities is simple for us to extract, so it's important they include everything you need!
It's good to hear that RUM gets you most of the way there though. Does it get you to the point where adding traces to the NavigationManager wouldn't actually give you any extra information? Or would that still be useful?
@andrewlock I will keep an eye out on the issue you mentioned!
RUM has been useful in that it allowed us to recreate all of the monitoring/alerts that we had defined in another APM vendor. I think the primary thing we are missing with RUM are the distributed trace integrations to give us deeper insight when there are performance problems. We have defined the allowedTracingUrls to link RUM and APM traces but the single long lived top-level _blazor span makes it pretty messy to sort through.
From that standpoint, I'm not sure adding instrumentation to the NavigationManager produces much value unless it can be done in a way where the spans are detached from that parent websocket trace.