Background
This regression was introduced in open-telemetry/opentelemetry-specification#3402, see comment thread from here: open-telemetry/opentelemetry-specification#3402 (comment)
Description
Previous semantic conventions used the concepts "peer" to indicate the remote end and "host" to indicate the local end of a network connection. It is now no longer generally possible to know which is which, as the new concepts of server/client and source/destination are orthogonal to that.
There is one common case in which the assignment can still be made for server/client: Spans, as long as they don't have INTERNAL as SpanKind can use the rule "if server/consumer kind then server is the local side, otherwise client".
There is also the case of metrics where the metric definition makes it clear whether the local side is the client or server, according to @AlexanderWert open-telemetry/opentelemetry-specification#3402 (comment). IIUC, this requires a case-by-case knowledge to define a mapping metric ID -> "is client or server the local side".
Besides these two particular cases, it seems now impossible to tell which side is the local vs. remote. Most commonly, this may affect logs, metrics which are not known to the system wanting to know the local/remote end, and any use of source/destination where the remote/local-ness is completely unclear.
Proposal
Introduce a new semantic attribute network.role which may be one of server, client, sender or receiver (closed set). Then the mapping is as follows:
| network.role |
server.* |
client.* |
source.* |
destination.* |
| server |
local |
remote |
not allowed |
not allowed |
| client |
remote |
local |
not allowed |
not allowed |
| sender |
not allowed |
not allowed |
local |
remote |
| receiver |
not allowed |
not allowed |
remote |
local |
For peer to peer operations, esp. using source/destination, there may be cases where in a single operation that a metric/span/log line is recorded for, both the role of sender and receiver applies. In this case, the role should be arbitrarily chosen (by default, I suggest "sender") and source/destination attributes set consistently to allow correct local/remote attribution. It would also be possible to define an additional role "mixed" with same mapping as "sender" or define that role remains unset and "source" is by default the local end and "destination" the remote end.
Bikeshedding alternative: network.position instead of network.role would work as well, with values corresponding 1:1 to the prefixes that are then local, i.e. one of server/client/source/destination.
CC @lmolkova @trask
Background
This regression was introduced in open-telemetry/opentelemetry-specification#3402, see comment thread from here: open-telemetry/opentelemetry-specification#3402 (comment)
Description
Previous semantic conventions used the concepts "peer" to indicate the remote end and "host" to indicate the local end of a network connection. It is now no longer generally possible to know which is which, as the new concepts of server/client and source/destination are orthogonal to that.
There is one common case in which the assignment can still be made for server/client: Spans, as long as they don't have INTERNAL as SpanKind can use the rule "if server/consumer kind then server is the local side, otherwise client".
There is also the case of metrics where the metric definition makes it clear whether the local side is the client or server, according to @AlexanderWert open-telemetry/opentelemetry-specification#3402 (comment). IIUC, this requires a case-by-case knowledge to define a mapping metric ID -> "is client or server the local side".
Besides these two particular cases, it seems now impossible to tell which side is the local vs. remote. Most commonly, this may affect logs, metrics which are not known to the system wanting to know the local/remote end, and any use of source/destination where the remote/local-ness is completely unclear.
Proposal
Introduce a new semantic attribute
network.rolewhich may be one ofserver,client,senderorreceiver(closed set). Then the mapping is as follows:For peer to peer operations, esp. using source/destination, there may be cases where in a single operation that a metric/span/log line is recorded for, both the role of sender and receiver applies. In this case, the role should be arbitrarily chosen (by default, I suggest "sender") and source/destination attributes set consistently to allow correct local/remote attribution. It would also be possible to define an additional role "mixed" with same mapping as "sender" or define that role remains unset and "source" is by default the local end and "destination" the remote end.
Bikeshedding alternative: network.position instead of network.role would work as well, with values corresponding 1:1 to the prefixes that are then local, i.e. one of server/client/source/destination.
CC @lmolkova @trask