Problem Statement
When used with a gRPC server, otelgrpc does not seem to emit span/metric attributes identifying the endpoint address or port number. This is problematic for its use in the OTLP receiver, as we want to make sure users can identify which receiver instance emitted a span/metric when multiple gRPC endpoints are configured, and the last resort of comparing the port number with the receiver config is not currently possible.
Under the 1.17.0 semantic convention (for spans / for metrics), which seems to be the one that is currently implemented, this would correspond to the net.host.name, net.sock.host.addr, net.sock.host.addr span attributes, and the net.host.name, net.host.port metric attributes. Notably, net.host.name has "Required" status, and net.host.post is conditionally required.
The corresponding server.address and server.port attributes in the latest 1.29.0 semantic convention (for spans / for metrics) are actually "Required" for spans, so they would have to be implemented as part of a convention version upgrade.
Proposed Solution
Emit net.sock.host.addr and net.sock.host.port attributes. If I'm not mistaken, I believe this information can be obtained from the LocalAddr field in the ConnTagInfo and InHeader structs received in the stats handler.
Alternatives
An alternative for users would be to manually setup these attributes by passing WithSpanAttributes/WithMetricAttributes options to NewServerHandler.
Prior Art
otelhttp provides the similar net.host.name and net.host.port, although those seem to be derived from the HTTP Host header.
Problem Statement
When used with a gRPC server,
otelgrpcdoes not seem to emit span/metric attributes identifying the endpoint address or port number. This is problematic for its use in the OTLP receiver, as we want to make sure users can identify which receiver instance emitted a span/metric when multiple gRPC endpoints are configured, and the last resort of comparing the port number with the receiver config is not currently possible.Under the 1.17.0 semantic convention (for spans / for metrics), which seems to be the one that is currently implemented, this would correspond to the
net.host.name,net.sock.host.addr,net.sock.host.addrspan attributes, and thenet.host.name,net.host.portmetric attributes. Notably,net.host.namehas "Required" status, andnet.host.postis conditionally required.The corresponding
server.addressandserver.portattributes in the latest 1.29.0 semantic convention (for spans / for metrics) are actually "Required" for spans, so they would have to be implemented as part of a convention version upgrade.Proposed Solution
Emit
net.sock.host.addrandnet.sock.host.portattributes. If I'm not mistaken, I believe this information can be obtained from theLocalAddrfield in theConnTagInfoandInHeaderstructs received in the stats handler.Alternatives
An alternative for users would be to manually setup these attributes by passing
WithSpanAttributes/WithMetricAttributesoptions toNewServerHandler.Prior Art
otelhttpprovides the similarnet.host.nameandnet.host.port, although those seem to be derived from the HTTPHostheader.