Add openapi processor for trace enrichment (url.template, peer.service) in an automated way

[Apoorva64]

Component(s)

cmd/otelcontribcol

Is your feature request related to a problem? Please describe.

Let's say we have 2 REST services Service A (serviceA.mysupercompagny.com) and Service B (serviceB.mysupercompagny.com). Where service A calls service B on the endpoint GET /item/{itemId}

I want to observe the system with opentelemetry to derive RED metrics of the services and their dependencies. An example question would be: "How many times did Service A call Service B on route GET /item/{itemId}?", "How many of those failed?"

This can be done using distributed tracing and using the Span Metrics Connector to derive the metrics. However, when instrumenting Service A, the tracing layer does not inherently know that it is “calling Service B” — it only sees a request to an IP address or domain name so we can't reliably set "peer.service". Additionally, the instrumentation typically captures the full request URL but lacks a low-cardinality representation of the request (/item/{itemId}) url like "url.template".
So the problem is that we are missing a way to reliably include "peer.service", "url.template" information in an automated fashon

Describe the solution you'd like

REST services are typically described using an OpenAPI specification, which defines the service name and its available endpoints. One possible approach is to derive regular expressions from this specification and use them in a processor to match the http.url attribute of traces to a specific Operation. The processor could then enrich the trace by adding the peer.service attribute and the url.template attribute as defined in the OpenTelemetry HTTP semantic conventions.

An example implementation of this approach is available in this PR: #45304.

Describe alternatives you've considered

Another alternative is to move the problem closer to developers. OpenAPI specifications
can be used to generate clients in many languages, which opens another path to populate the peer.service and url.template attributes. This could be achieved by collaborating with client generators—such as OpenAPI Generator — so that they either directly integrate OpenTelemetry support or expose this metadata in a way that existing instrumentations can easily pick up and propagate it.

see OpenAPITools/openapi-generator#22620

Additional context

see also slack thread https://cloud-native.slack.com/archives/CJFCJHG4Q/p1767887131579019

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}