[http.server.request.duration] New origin.name attribute

[alexa-gt]

Area(s)

http.server.request.duration

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

Background

I was using instrumentation-http with the sdk-node autoinstrumentation and I could not find seem to find an option for me to be able to specify that a custom attribute I added to a span in requestHook or headersToSpanAttributes.

The use case for this would be to identify traffic flow per client of an internal microservice application.

flowchart LR
    B --> A
    C -->|HTTP/GRPC + 'X-Origin' header/metadata| A
    D --> A

Loading

This would be highly valuable in detecting spikes from some upstream service or checking if some % of problematic traffic comes from some origin service as the immediate parent.

Describe the solution you'd like

Proposal

Add an origin.name attribute to be able to segregate inbound metrics on A by direct clients. The field value should correspond to service.name of the upstream, in the above case, B, C or D.

Describe alternatives you've considered

No response

Additional context

No response

[lmolkova]

[UPDATE] Please take a look at the existing peer.service attribute -

semantic-conventions/docs/attributes-registry/peer.md

Line 15 in aead156

| `peer.service` | string | The [`service.name`](/docs/resource/README.md#service) of the remote service. SHOULD be equal to the actual `service.name` resource attribute of the remote service if any. | `AuthTokenCache` |  |

I believe it fits for the use-case perfectly.

Propagating service name in the headers looks like a very custom solution.

If the intention is to make all HTTP server instrumentations enrich metrics with it, there need to be a common general-purpose solution that defines a propagation mechanism. It might be a good idea to outline the whole solution and share it as an OTEP or at least start a discussion in the specification repo.

Keep in mind that adding new attributes to metrics is a breaking change and should be handled with caution - #722.

One more thing to keep in mind is that http client metrics coming from upstream services already have all the information, so, if you have access to their telemetry, it could be easier to analyze it rather than propagate service name downstream.

If the intention is to have custom propagation solution and use custom server instrumentation, then please share some context why common standard attribute is necessary.