server response time needs to ignore signalr
The average response time metric is not very useful if it is counting signalr persistent connections. I can't filter out these requests in the default dashboard graphs and it's a pain to filter it out in every single graph I create. There needs to be a way to ignore certain patterns from being tracked.
Travis Ellis
shared this idea
Thank you all for sharing the feedback and upvoting for this feature. It is something being reviewed internally by the team and will be considered in the next wave of planning.
14 comments
-
Anonymous
commented
I thought I was living in a dream world with Application Insights. Everyone at the company was pleased with it. Then we deployed SignalR and now the dashboard is worthless. Numbers are puffier than a kid having an allergic reaction.
Please restore the Dream!!! Thanks
-
Anonymous
commented
We build a Blazor Webassembly application within our ASP.NET Core application. In the blazor app we use SignalR which totally ruins the metric for average response time.
Please fix this issue.
-
Anonymous
commented
Thanks for highlighting this issue <3
-
GP
commented
I've been wrestling with this issue as well - and found the following post that appears to show a decent example of how to filter out signalr traffic:
https://github.com/microsoft/ApplicationInsights-Home/issues/445#issuecomment-579239919
-
SimonS
commented
Would be good to get this fixed.
Seems from responses etc. the the AI team don't perhaps understand how SignalR works (perceived as long running requests), and should perhaps set up a demo to see ? The HTTP request is encapsulation a web socket connection, and is should due possible to detect that given the HTTP handshake ?
"SignalR is an abstraction over some of the transports that are required to do real-time work between client and server. A SignalR connection starts as HTTP, and is then promoted to a WebSocket connection if it is available."
-
Shane Courtrille
commented
We are looking at alternative solutions just to get rid of this stupid signalr noise in our failures. It makes the blade completely useless
-
Dan Oliver
commented
This feedback is fast approaching it's fifth birthday. Is this going to be looked at? Or do we need to look elsewhere for useful metrics?
-
Shane Courtrille
commented
2020 and this is still an issue? Looking at other vendors.. *sigh*
-
Howard Hoffman
commented
We'd like Signal R data to be filtered out of the App Insights default 'Performance' blade query. We often see this dominated by Signal R Reconnects and Ping. While interesting from a "is SignalR healthy / using-WebSockets / etc.' perspective it's not at all interesting from a Performance perspective.
-
Kristian Williams
commented
This is an absolute nightmare for our real time monitoring.
A single SignalR websocket connection active for 15h managed to completely destroyed a days worth of our metric trends.
Even if you don't and support specifically for SignalR, just having a global filter option in the Application Insights settings would be a huge help. -
Ojas
commented
Hi Michael, any updates on this feature?
-
We are looking to add exclusion filtering capabilities for operational names in our upcoming UX iteration. Please stay tuned and keep up-voting.
Best,
Michael Milirud
-AI Product Team -
Mikey Cooper
commented
Top 4 in the poorly performing operations list under Performance are SignalR every single time for me:
GET /signalr/reconnect
POST /signalr/poll
POST /signalr/reconnect
GET /signalr/connectMakes noise in avg dependency time as well. And total dependency failures when using long-polling. Server Requests. Failed Requests.
Pretty much every chart and list I have to measure worst performers includes SignalR long-polls, pings, reconnects, etc.
-
Can you please offer a more concrete example? Are you building dashboard graphs by pinning ME blades or by writing Analytics queries?
Best,
Michael Milirud
-AI Product Team