Adds extended span name.

[dimaKudr]

No description provided.

[welcome]

Thanks for opening your first pull request! If you haven't yet signed our Contributor License Agreement (CLA), then please do so that we can accept your contribution. A link should appear shortly in this PR if you have not already signed one.

[linux-foundation-easycla]

• ❌ - login: @dimaKudr / name: Dmytro Kudryavtsev . The commit (aa230a6) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[weslenteche]

@dimaKudr According to the semantic convention documentation - "HTTP client spans have no http.route attribute since client-side instrumentation is not generally aware of the “route”, and therefore HTTP client span names SHOULD be {method}.".

[dimaKudr]

hi @weslenteche. thank you for your response. I have checked the convention mentioned in docs and I don't find it convenient. but maybe I miss something. could you please take a look at the screenshot here? it represents a real Trace from our system. you can see there several spans to Mongo and 2 spans generated by Guzzle http client. Both Guzzle spans have the same GET method. Without the host name mentioned in those spans they will look the same and very non-informative. BTW, you can see that every Mongo span has collection and query name in its title. It looks pretty similar to what I propose for Guzzle spans.

[weslenteche]

hi @weslenteche. thank you for your response. I have checked the convention mentioned in docs and I don't find it convenient. but maybe I miss something. could you please take a look at the screenshot here? it represents a real Trace from our system. you can see there several spans to Mongo and 2 spans generated by Guzzle http client. Both Guzzle spans have the same GET method. Without the host name mentioned in those spans they will look the same and very non-informative. BTW, you can see that every Mongo span has collection and query name in its title. It looks pretty similar to what I propose for Guzzle spans.

Information regarding hostname, URL, for example, will be located in the span attributes. This client span has some attributes such as url.full and server.address that can help you in the analysis process.

In my opinion, by mixing this we will be opening gaps to not follow the standards of the semantic convention. But I also wanted the opinion of the @brettmc @bobstrecansky

[brettmc]

This looks very similar to #190 which was proposed for the same reason and rejected on the basis of spec-conformance, which @weslenteche mentioned and linked to earlier.

If you look at other implementations, I think you'll find other SIGs are following the spec and doing the same thing that we are with http span names.

re: mongo (database) spans, they're also following spec: https://opentelemetry.io/docs/specs/semconv/database/database-spans/

The span name SHOULD be set to a low cardinality value representing the statement executed on the database

IMO, if you feel really strongly about this change, then start with the spec. I couldn't find an exact matching issue, however open-telemetry/semantic-conventions#899 is similar. Perhaps using {method} {hostname} avoids the cardinality explosion concerns referred to in that issue?