Change peer.service to service.origin.name and service.target.name?

[trask]

@AlexanderWert to confirm that ECS doesn't have an equivalent to peer.service.

ECS service.* fields can be self-nested under service.origin.* and service.target.*, which has a similar purpose as the peer.service in OTel. Similar to our previous discussions on client / server and source / destination, here service.origin.* and service.target.* make the relationship more explicit, without the need to know the context of the field.

_Originally posted by @AlexanderWert in #1012

[Oberon00]

service.peer is AFAIK only explicitly configured. By extending this to service.origin/target, you'd need to make the configuration more complex (and e.g. if you call an auth service, is it then the target (of your call) or the origin (of the data)?)

Why introduce another concept "origin" vs "target" when we already have "source" and "destination" in ECS (and had "host" and "peer" in OTel)

[trask]

maybe (client|server|source|destination).service.name? so that it's clearly grouped with the other (client|server|source|destination).* attributes in a given context

[Oberon00]

I think that would already be an improvement, but OTOH then it is neither ECS-aligned, nor compatible with old conventions, and I also still don't see the value in the distinction for this attribute?

[trask]

I think the value is similar to the value for client.*/server.*/source.*/destination.*, which is that they are more generally useful on logs where the concept of SpanKind is not inherent in the data model.

[Oberon00]

We could add an attribute like otel.span_kind on any telemetry item supporting attributes (name inspired by https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/mapping-to-non-otlp.md).

[lmolkova]

having service.origin.name and sevice.target.name would allow to:

• use them on the same telemetry item (e.g. a log record that apply to both services)
• having 1 attribute instead of 2 (span_kind would mean someone needs to set 2 attributes to identify which side peer.service applies to)
• easier to query and more obvious when looking at the telemetry on what it means