Span.OperationName should use ActivitySource.Name

[lukeemery]

A recent change introduced issues with how DD will collect from the dotnet diagnostic tooling.

https://github.com/DataDog/dd-trace-dotnet/pull/4409

We should source the operation name from ActivitySource.Name, and resource name should come from the Activity.DisplayName.

What is used to look like:

And what it looks like now:

[bouwkast]

Hi @lukeemery thanks for raising this

We discussed this today and we're going to swap the environment variable added in that #4409 PR to default to true so that the previous behavior becomes the default again. PR here #4461 I do want to note though that we aren't entirely sure what the DD.OperationName should map to from OpenTelemetry, so this may change in the future.

Before #4461 gets released the way to get back to the old behavior would be to set the "DD_TRACE_OTEL_LEGACY_OPERATION_NAME_ENABLED" environment variable to true.

[lukeemery]

In thinking about it more I do agree that there are many paths to take here. Choosing one is simple but then it will impose on the variants. Not easy choices.

Thank you for making that adjustment. Is there anything that I could do here to help?

[kadufmoraes]

Hi @lukeemery

I saw that this issue is based on a consumer. Is your consumer a hosted service? I'm having an issue to send metrics from a hosted service. I have opened an issue in this link. Can you help me with my issue?

[bouwkast]

Hi @lukeemery,

We've implemented a new mapping scheme for the Datadog.Span.OperationName for OpenTelemetry/Activity. This should be out in our next version, 2.42.0, which should be sometime next week (week of November 20th).

The new mapping will use a combination of Activity.Kind along with various tags on the span to craft an OperationName that should be more consistent with a normal OperationName from Datadog.

For example, a server Span with an http.request.method tag would have an OperationName of http.server.request.

A few things to note here:

• This will be the default mapping for OperationNames from OpenTelemetry/Activity.
• Setting DD_TRACE_OTEL_LEGACY_OPERATION_NAME_ENABLED to true will use the $"{Activity.Source.Name}.{Activity.Kind}" as the OperationName
• If the Span has an operation.name tag, then that value will be used as the OperationName (overriding the above mappings).

This new mapping will also be consistent throughout the different Datadog tracers (if that applies)

The PR for it: #4700

[lukeemery]

@bouwkast thanks for following up on this, and I appreciate your work to make it better. It does look like a promising change and I am excited to try it out.

Though we recently noticed that tags were not being collected sometime after 2.31.0, so we reverted some of our lambdas to that version and they appeared again. If that hasn't been resolved/identified yet then it would probably impact on this.

[lukeemery]

@bouwkast

There are some idiosyncrasies that will need to be addressed. Is there a way that I can share traces with you?

Immediate examples:

• sqs.send is used when we are actually publishing to sns
• receiving a message from sqs has an operation name of consumer

I want to say that I am excited to work through these issues. I believe this PR is much better, but there is clearly some edge cases to cover.