Add "code" attribute to spans every time it is possible

[FBibonne]

In order to better understand bugs into a single app component, I suggest it would be usefull to add "code.function", "code.namespace" and "code.lineno" attributes to spans when it is possible. The issue #7345 is limited to controller spans so I suggested to extend it to every span where possible.

Instead of rewriting every instrument, I wonder if it is possible to write an agent extension which would systematically add the code.* attributes to the span.

[laurit]

@FBibonne could you provide samples where you believe code. function and code.namespace are currently missing but would be useful.

[github-actions]

This has been automatically marked as stale because it has been marked as needing author feedback and has not had any activity for 7 days. It will be closed automatically if there is no response from the author within 7 additional days from this comment.

[FBibonne]

The first sample I think about is "jdbc span" : you see the SQL request but you don't know which line of code triggered it and if the SQL request is not specific enough, you can't guess the line of of code.

I have to redo my trials to give more samples. But to my mind, if you monitor a legacy code which is not instrumented with business spans, you may have difficulty to find where a slow trace (SQL, http client, ...) come from to fix it.

[laurit]

The first sample I think about is "jdbc span" : you see the SQL request but you don't know which line of code triggered it and if the SQL request is not specific enough, you can't guess the line of of code.

Usually code.function and code.namespace point to the code that created the span (see https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/span-general.md#source-code-attributes), which in case of jdbc happens inside the PreparedStatement implementation class (jdbc driver code, or our jdbc driver wrapper in case of manual instrumentation) and would report the same values for all prepared statements. As you can see it wouldn't really help in determining where the query originates from. An alternative would be to use the caller of the PreparedStatement which could return useful info when jdbc api is used directly, but if it is accessed through an abstraction, like spring jdbc support classes, it would still point inside the library code and be useless.

[github-actions]

This has been automatically marked as stale because it has been marked as needing author feedback and has not had any activity for 7 days. It will be closed automatically if there is no response from the author within 7 additional days from this comment.