-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[AzureMonitorexporter] fix operation name #41623
Conversation
@TimothyMothra Could you confirm if the output with this change matches with the output when exporter without this change is used with 1.6.0-beta.3 version of the instrumentation library? |
API change check API changes are not detected in this pull request. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Thank you for this! |
...pNetCore/tests/Azure.Monitor.OpenTelemetry.AspNetCore.Demo/Controllers/CustomerController.cs
Outdated
Show resolved
Hide resolved
Routes should not be fully populated in the names if you don't want to blow up cardinality on requests i.e. when you go to app insights, you should see something like /MyController/MyAction/{id} and not /MyController/MyAction/123, otherwise you can't get accurate statistics in most views for request timing etc. It is of course better than /{Controller}/{Action}/{id}, and I'm not even sure how this populates all the route fields with these changes? |
Co-authored-by: Vishwesh Bankwar <vishweshbankwar@users.noreply.github.com>
Closing this PR for now. Tracking the issue here: #41650 |
When using Asp.Net Core Routing rules, our Exporter is currently recording the full pattern as the Operation Name.
This means that requests to different Controllers or Actions will show identical Operation Names, as shown in this screenshot.
This can be reproduced in an MVC app configured like this:
My test app has a
HomeController
andCustomerController
. Regardless which controller is invoked, Theurl.path
shows the correct Controller/Action. Thehttp.route
shows the configured pattern.https://localhost:44311/Home/Index
https://localhost:44311/Customer/Index
This is in part due to the data provided by the OpenTelemetry.Instrumentation.AspNetCore library, where the configured pattern is used as
http.route
. This is a known issue in that library: open-telemetry/opentelemetry-dotnet-contrib#1730Changes
TraceHelper
to better handle cases wherehttp.route
contains a controller pattern.With this change: