You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem?
We develop and run a couple of ASP.NET Core applications using Razor pages. The pages structure makes use of areas related to different parts of our applications. Within one area, we often use the same page names for the same overall functionality, such as "/Index" for entity lists or "/Detail" for detail pages. We also make use of page handlers to implement different operations on single pages.
The current implementation automatically generates an Operation name, which only consists of the HTTP method and page name (in the HostingDiagnosticListener class). This leads to many similar entries like "GET /Index" or "GET /Detail" in the AppInsights dashboard, representing very different operations within the application. This is especially annoying in the "Performance" tab when trying to drill down on pages with high request durations.
Describe the solution you'd like.
I'd suggest to simply prepend the area name to the page name, if present. So instead of having "GET /Index" one would see "GET Xxx/Index" and "GET Yyy/Index" as separate operations.
If a page handler is used, it could be appended like "Get Yyy/Index[Handler]" (or any other naming scheme)
In my opinion adding the area could simply be implemented by adding a couple of lines to the code of "HostingDiagnosticListener" since the area is available in the routing values. As for the handler name I'm not yet sure how to get this one in the context of the HostingDiagnosticListener.
It might also be a good idea to add the area for controllers (altough we only use them very rarely).
Describe alternatives you've considered.
Our current solution is to use an IAsyncPageFilter to overwrite the name of the current RequestTelementry. The filter mostly repeats the code found in HostingDiagnosticListener.GetNameFromRouteContext().
A previous attempt to use an ITelementryInitializer was not successful because at the time telemetry is initialized the router has not yet run and therefore the route values (for "page" and "area") are not known.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?
We develop and run a couple of ASP.NET Core applications using Razor pages. The pages structure makes use of areas related to different parts of our applications. Within one area, we often use the same page names for the same overall functionality, such as "/Index" for entity lists or "/Detail" for detail pages. We also make use of page handlers to implement different operations on single pages.
The current implementation automatically generates an Operation name, which only consists of the HTTP method and page name (in the
HostingDiagnosticListener
class). This leads to many similar entries like "GET /Index" or "GET /Detail" in the AppInsights dashboard, representing very different operations within the application. This is especially annoying in the "Performance" tab when trying to drill down on pages with high request durations.Describe the solution you'd like.
I'd suggest to simply prepend the area name to the page name, if present. So instead of having "GET /Index" one would see "GET Xxx/Index" and "GET Yyy/Index" as separate operations.
If a page handler is used, it could be appended like "Get Yyy/Index[Handler]" (or any other naming scheme)
In my opinion adding the area could simply be implemented by adding a couple of lines to the code of "HostingDiagnosticListener" since the area is available in the routing values. As for the handler name I'm not yet sure how to get this one in the context of the
HostingDiagnosticListener
.It might also be a good idea to add the area for controllers (altough we only use them very rarely).
Describe alternatives you've considered.
Our current solution is to use an
IAsyncPageFilter
to overwrite the name of the current RequestTelementry. The filter mostly repeats the code found inHostingDiagnosticListener.GetNameFromRouteContext()
.A previous attempt to use an
ITelementryInitializer
was not successful because at the time telemetry is initialized the router has not yet run and therefore the route values (for "page" and "area") are not known.The text was updated successfully, but these errors were encountered: