Fix: http_route is not recorded by server metric while using servlet 2/3 #12353

[k3v1n1k88]

Class ServletHttpAttributesGetteralways returns null for the getHttpRoute() function because it does not override the getHttpRoute() method. As a result, the class uses the default function from its superclass and http_route will be assigned to null

[linux-foundation-easycla]

• ❌ The email address for the commit (e221279) is not linked to the GitHub account, preventing the EasyCLA check. Consult this Help Article and GitHub Help to resolve. (To view the commit's email address, add .patch at the end of this PR page's URL.) For further assistance with EasyCLA, please submit a support request ticket.

[laurit]

The description of http.route in https://opentelemetry.io/docs/specs/semconv/attributes-registry/http/#http-attributes states that MUST NOT be populated when this is not supported by the HTTP server framework as the route attribute should have low-cardinality and the URI path can NOT substitute it.
If you are using a higher level framework you should instead check whether that framework provides something that could be used as a route and write instrumentation that sets the route for that framework.

[k3v1n1k88]

The description of http.route in https://opentelemetry.io/docs/specs/semconv/attributes-registry/http/#http-attributes states that MUST NOT be populated when this is not supported by the HTTP server framework as the route attribute should have low-cardinality and the URI path can NOT substitute it. If you are using a higher level framework you should instead check whether that framework provides something that could be used as a route and write instrumentation that sets the route for that framework.

Hi @laurit, I see your idea. But if this attribute is missing, the metric will not be able to display the corresponding request URIs in the Server metric metric (all). This thing make us confused and can not use server metric of default opentelemetry. We have to custom another server metric for this label. Have you any idea for it?

[laurit]

Hi @laurit, I see your idea. But if this attribute is missing, the metric will not be able to display the corresponding request URIs in the Server metric metric (all). This thing make us confused and can not use server metric of default opentelemetry. We have to custom another server metric for this label. Have you any idea for it?

Metrics may not use high cardinality attributes such as URI, that is why we have the route. If you are using a higher level framework that builds on top of servlets it may be possible to extract route from there.

[k3v1n1k88]

Metrics may not use high cardinality attributes such as URI, that is why we have the route. If you are using a higher level framework that builds on top of servlets it may be possible to extract route from there.

Well, I think you mean we need to customize another HTTP server metric instead of using the default one provided by OpenTelemetry if we're using any framework that relies on a servlet version below v3, right?

[laurit]

Well, I think you mean we need to customize another HTTP server metric instead of using the default one provided by OpenTelemetry if we're using any framework that relies on a servlet version below v3, right?

No. Framework specific instrumentation provides the route that is used by the standard metrics. Have a look at https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md in Semantic Conventions column some frameworks have Provides http.route [2]. For these frameworks we have instrumentation that updates the route on the SERVER span.

[k3v1n1k88]

No. Framework specific instrumentation provides the route that is used by the standard metrics. Have a look at https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md in Semantic Conventions column some frameworks have Provides http.route [2]. For these frameworks we have instrumentation that updates the route on the SERVER span.

I see your point. So I think need to build another instrument (as extension) for server metric with servlet instead of use server metric of open telemetry in this situation.

Thanks for your review!

[laurit]

I see your point. So I think need to build another instrument (as extension) for server metric with servlet instead of use server metric of open telemetry in this situation.

What web framework are you using? Instrumenting the web framework to update the route would also work. Or you could call one of the update methods in https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation-api/src/main/java/io/opentelemetry/instrumentation/api/semconv/http/HttpServerRoute.java from your application code.

[k3v1n1k88]

What web framework are you using? Instrumenting the web framework to update the route would also work. Or you could call one of the update methods in https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation-api/src/main/java/io/opentelemetry/instrumentation/api/semconv/http/HttpServerRoute.java from your application code.

Currently, we are integrating with Jetty embedded (v9.x), which uses Servlet v3 to publish HTTP endpoints. While the update method mentioned above can address this issue, the default histogram with 10 buckets still causes the metrics to grow excessively. Do you have any ideas about customizing the configuration for this?