Clean Route setup in HTTP instrumentations

[dmathieu]

Now that we rely on the request.Pattern attribute to set the route attribute automatically (#6905), we should analyze all HTTP instrumentations that also set that attribute, and ensure the code can't be cleaned up to avoid repetition.

• otelmux @flc1125
• otelhttp: @Ananyasinha13
• otelgin: @arshukla98
• otelrestful
• otelecho (seems to use semconv attribute directly. It shouldn't)

[arshukla98]

Hi @dmathieu , I'd like to work on this issue. Could you please assign it to me?

[dmathieu]

This issue should actually bring multiple PRs, one for each instrumentation. I can add you to one of them. Which one would you like?

[arshukla98]

@dmathieu , I would like to take up otelgin instrumentation.

[dmathieu]

Done.

[Oloruntobi1]

otelecho (seems to use semconv attribute directly. It shouldn't)

Hi @dmathieu stumbled upon this conversation and wanted to pick this up (for otelecho) and from what i see it uses both https://github.com/open-telemetry/opentelemetry-go-contrib/blob/7af8c94c5b95671bdb17a997d2d9c0094a3a5036/instrumentation/github.com/labstack/echo/otelecho/echo.go#L14C2-L14C102 and

opentelemetry-go-contrib/instrumentation/github.com/labstack/echo/otelecho/echo.go

Line 18 in 7af8c94

semconv "go.opentelemetry.io/otel/semconv/v1.20.0"

This means the first work should trying to consolidate that like its been done for otelgin and others?

[Ananyasinha13]

hi @dmathieu can you assign otelhttp to me

[flc1125]

otelmux can be assigned to me.

[flc1125]

@dmathieu I checked all the related issues and PRs. I want to confirm the problems we need to address.

1. Check if related extensions (e.g., otelmux) have duplicate configurations for http.Route information.

2. If duplicates or incorrect configurations exist, they will be set based on request.Pattern, ensuring uniqueness.

3. It's possible that extension packages have their own set of route information. If conflicts arise here, we need to establish a priority order for configuring http.Route. If I understand correctly, should it be: extension package's route > request.Pattern?

Is my understanding correct?

[flc1125]

@dmathieu I checked all the related issues and PRs. I want to confirm the problems we need to address.

1. Check if related extensions (e.g., otelmux) have duplicate configurations for http.Route information.
2. If duplicates or incorrect configurations exist, they will be set based on request.Pattern, ensuring uniqueness.
3. It's possible that extension packages have their own set of route information. If conflicts arise here, we need to establish a priority order for configuring http.Route. If I understand correctly, should it be: extension package's route > request.Pattern?

Is my understanding correct?

@dmathieu Hello, is there any news?

[dmathieu]

It's possible that extension packages have their own set of route information. If conflicts arise here, we need to establish a priority order for configuring http.Route. If I understand correctly, should it be: extension package's route > request.Pattern?

You don't need this. If that happens, overriding attributes is fine.
Outside of that, your approach looks good.

[dmathieu]

One of the big issues with those changes is that not many frameworks are already using/setting req.Pattern. And it's not our role to set that value.
So I'm going to close this issue. We may want to review things on a per-framework basis as a cleanup thing later in the future.