todo: adhere to the HTTP span naming semconv processing checklist

[flc1125]

Based on #6365 (comment), organize the following list of items that need to be processed:

• go.opentelemetry.io/contrib/instrumentation/github.com/gorilla/mux/otelmux
• go.opentelemetry.io/contrib/instrumentation/github.com/gin-gonic/gin/otelgin
• go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp

If there are any omissions, please let me know.

Reference solution:

https://github.com/open-telemetry/opentelemetry-go-contrib/pull/6365/files

References:

• https://github.com/open-telemetry/opentelemetry-specification/blob/v1.20.0/specification/trace/semantic_conventions/http.md#name

[flc1125]

To avoid repetition, synchronize as follows:

I am processing this: go.opentelemetry.io/contrib/instrumentation/github.com/gin-gonic/gin/otelgin

[dmathieu]

I don't think we should remove the custom span methods.

See open-telemetry/opentelemetry-collector#11230
As a valid use of a custom span name.

[flc1125]

@dmathieu @pellared

Hello, since there are some questions at present, I want to discuss them together.

Information:

• At present, there are still situations in the community that expect customizable span names;
• But standard semantics suggest a fixed format.

So my current thoughts are:

• Keep customizable span naming, but mark it as obsolete through comments, explain the use of standard semantic annotations, and recommend using the default naming format
• Change the default naming of all related tables to standard semantics.

---

Because there is a difference from the previous treatment method. Therefore, I would like to invite the two of you to discuss it together and see how to deal with it.

---

reference:

• [confighttp]: add an option to add span formatter opentelemetry-collector#11230
• otelgin: update default span name to align with semantic conventions #6381 (review)

[pellared]

I think this can be split this into two issues:

1. Change the default span naming to adhere to semantic conventions
2. Deprecate (and later remove) SpanNameFormatter

We may decide just to address the first issue if there would be a push-back to keep SpanNameFormatter

[flc1125]

I think this can be split this into two issues:

1. Change the default span naming to adhere to semantic conventions
2. Deprecate (and later remove) SpanNameFormatter

We may decide just to address the first issue if there would be a push-back to keep SpanNameFormatter

Good idea, I will first solve the first problem. For the second problem, I will leave it as is for now.