Create a better `OperationName` for `Activity`/`OpenTelemetry` #4700

bouwkast · 2023-10-05T21:22:55Z

Summary of changes

This change aims to craft a more suitable value for our OperationName for OpenTelemetry Spans/Activity. I'm using OpenTelemetry Span and Activity interchangeably here. With this change, the default OperationName will now be calculated from a combination of Activity.Kind and various tags/tag values within Activity.Tags.

This changes the default Span.OperationName from being mapped to the Activity.OperationName to one that more closely resembles the standard Datadog OperationName.

Reason for change

Before this, the OperationName was set to one of the following:

Value of the tag operation.name on the Activity.Tags, if present
Value of Activity.OperationName
Value of $"{Activity.Source.Name}.{Activity.Kind}" only when DD_TRACE_OTEL_LEGACY_OPERATION_NAME_ENABLED was set to true
Value of $"opentelemetry.{Activity.Kind}" if Activity.Source.Name isn't available and DD_TRACE_OTEL_LEGACY_OPERATION_NAME_ENABLED was set to true

The default was changed to Activity.OperationName to better align with other Datadog tracing libraries instead of $"{Activity.Source.Name}.{Activity.Kind}". This change produced less than desirable OperationName values.

Implementation details

By default, OperationName will now be calculated from a combination of Activity.Kind and various tags/tag values within Activity.Tags.

For example, an Activity with an Activity.Kind of Server and a tag of http.request.method will result in an OperationName of http.server.request.

Refer to our unit tests to see more mapping examples of potential OperationName values.

Setting the OperationName from Activity will now be controlled by the following:

If the tag operation.name is present with a value, the OperationName will be set to that.
- All other mappings will be ignored for the OperationName.
If DD_TRACE_OTEL_LEGACY_OPERATION_NAME_ENABLED is set to false (default), the OperationName will be determined based on Activity.Kind and various tags in Activity.Tags.
If DD_TRACE_OTEL_LEGACY_OPERATION_NAME_ENABLED is set to true the OperationName will be set to $"{Activity.Source.Name}.{Activity.Kind}" or $"opentelemetry.{Activity.Kind}"

Users that currently have DD_TRACE_OTEL_LEGACY_OPERATION_NAME_ENABLED set to true (not the default) shouldn't see a change in their OperationName values from this and they will remain as $"{Activity.Source.Name}.{Activity.Kind}" or $"opentelemetry.{Activity.Kind}".

I've added an OpenTelemetryTags implementation - this seems a bit different that other ...Tags classes as it isn't really the tags that one will see on these spans, it is all of the tags that are used for the mapping. When the Activity is closed we copy the tags over to the backing Span.

I've also made it so that ActivityStarted requires an OpenTelemetryTags instead of an ITags to ensure that we will be able to do the mapping. Also made it so that AzureServiceBusTags inherits from OpenTelemetryTags so that it gets mapped too.

Test coverage

Copied the parametric test data into unit tests
Additionally added unit tests that assert that the "reserved" attributes map correctly
Added same data to the OpenTelemetrySdk and NetActivitySdk Samples
Updated various snapshots that use Activity for manual instrumentation
AzureServiceBus checks and snapshots have been updated for the new operation name

Other details

I need to validate that the parametric tests actually pass locally, I'll do that before this gets merged.

OperationName parametric tests pass (I tested locally with the NuGet built from one of these runs)

datadog-ddstaging · 2023-10-05T21:44:48Z

Datadog Report

Branch report: steven/otel-operation-name
Commit report: 30913b2

❌ dd-trace-dotnet: 488 Failed (0 Known Flaky), 0 New Flaky, 304138 Passed, 1060 Skipped, 30m 26.65s Wall Time