[REQ] Generate observability metadata from OpenAPI specs

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

Consider two services, Service A and Service B, where Service A calls Service B using endpoints such as /item/123 or /item/321. From an observability perspective, I want to be able to answer questions like:

• How many times did Service A call Service B?
• Did those requests fail?

This is typically handled using observability tooling such as OpenTelemetry with distributed tracing. 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. Additionally, it lacks a low-cardinality representation of the request (e.g. /item/{id} instead of /item/123).

As a result, important metadata such as peer.service and url.template must currently be added manually in the application code.

Describe the solution you'd like

I believe this information could be automatically derived from the OpenAPI specification, for example:

• Using the API title to identify the called service
• Using the paths object to provide a URL template (e.g. /item/{id})

This would allow generated clients to expose or emit the necessary metadata for observability tooling without requiring manual instrumentation in every service.

Describe alternatives you've considered

I see two possible approaches:

1. Expose metadata in generated clients
   Generate metadata such as peer.service and url.template and make it accessible (for example via client options or configuration), so that an OpenTelemetry instrumentation layer or middleware can consume it.
   Example: in the php-nextgen generator, passing this data via client options and using a middleware to add tracing attributes.

2. Direct OpenTelemetry integration
   Integrate OpenTelemetry support directly into the generated clients, so spans and attributes are created automatically.

Additional context

I’d be happy to contribute an implementation if this feature is deemed valuable.

Start by reviewing the generated-client architecture and the OpenAPI Info and Paths objects described in the issue. Compare the two proposed approaches, using the linked php-nextgen api.mustache and OpenTelemetry middleware as examples. Done should mean a defined, tested way for generated clients or integrations to expose the service name and low-cardinality URL template.