[BUG] OpenTelemetryExporter prevents setting the span name for Request telemetry #44971
Labels
Client
This issue points to a problem in the data-plane of the library.
customer-reported
Issues that are reported by GitHub users external to the Azure organization.
Monitor - Exporter
Monitor OpenTelemetry Exporter
needs-team-attention
Workflow: This issue needs attention from Azure service team or SDK team
question
The issue doesn't require a change to the product in order to be resolved. Most issues start as that
Service Attention
Workflow: This issue is responsible by Azure service team.
Library name and version
Azure.Monitor.OpenTelemetry.Exporter 1.2.0
Describe the bug
OpenTelemetryExporter overrides
Activity.DisplayName
with hard-coded logic for Request telemetry, which effectively makes it impossible to set the span name for requests. So, if a developer is able to figure out open-telemetry/opentelemetry-dotnet-contrib#1948 and determine that they have to set theActivity.DisplayName
sometime after the request Activity has stopped, that value is ignored when the AppInsights telemetry is generated by the exporter - the exporter re-creates the default value that was replaced and ignores the overridden value.Expected behavior
The value set in
Activity.DisplayName
should be used for request telemetry in the Request.Name and OperationName values.DisplayName
should provide a good default (which it does), but the developer should be able to override it to make their telemetry more useful.This is both the correct behavior, and I believe is consistent with App Insights classic.
Actual behavior
The value set in
Activity.DisplayName
is ignored; instead the logic used by the OpenTelemetry AspNetCore instrumentation is roughly repeated and the re-computed value is used for the Request.Name and OperationName.Reproduction Steps
Here's a test (that runs in the
Azure.Monitor.OpenTelemetry.Exporter.Integration.Tests
project b/c there's no other reasonable way to validate the telemetry values):Environment
The text was updated successfully, but these errors were encountered: