Add code attributes to play mvc controller spans

[jaydeluca]

Related to #7345

I know there are still discussions (here and here) around these conventions, but figured another example might help us continue to validate

Is this the right approach?

[trask]

Is this the right approach?

👍

cc @SylvainJuge

[laurit]

In my opinion this is not useful. It points to framework code and is the same for all endpoints.

[SylvainJuge]

I tend to agree with Lauri here, if the value is the same for all spans then it does not provide much value for the end-user as with it they can't guess which part of the application code is related to the span.

We will very likely have exactly the same kind of issues with Webflux or other reactive frameworks where the application code is provided through nested lambdas and can't be described with a dedicated class/method. For those cases, the "span identity" should be provided through other attributes for example HTTP verb, path or span name which allows the end-user to understand the link with application code.

If we capture this technical and implementation-specific information, do we have a way to make any good use of it ?

One example I could think of is if we attempt to correlate those attributes with another source of information like inferred spans or profiling, however for those the correlation would be implemented through trace and span ID rather than on those code-level attributes.

I think this example is really interesting from the perspective of semconv attributes clarification as there are at least two distinct use-cases for those attributes:

• provide more information about a span for the end-user: we may recommend to capture information that is related to the application code rather than framework/library details
• capture "technical information" in a structured way that could not be described otherwise: profiling, inferred spans, ...