Prototyped AMQP instrumentation in Java inside Azure SDK built on top of Apache Qpid Proton library.
Findings:

Java's SocketAddress and its implementations map well to network.* attributes.
Figuring out network.transport could be tricky as it needs to be deduced from multiple things:
- the type of SocketAddress ( InetSocketAddress or UnixDomainSocketAddress). Specific libraries may have their own socket implementations (e.g. netty has DomainSocketAddress). Instrumentations need to know which implementations are available in their ecosystem. .NET has the same behavior where EndPoint implementation type is a marker of transport.
- Java's UnixDomainSocketAddress was added in Java 16 which could create problems for instrumentations/libs that use earlier versions as a baseline
- UDP runs on top of IP, to distinguish it from TCP, we need to look at SocketChannel implementation type (DatagramChannel presumably points to UDP). A similar problem exists on .NET.
Qpid library we use for AMQP stack does not really expose a socket address through public APIs (or it's not a trivial task). A bit of semi-public reflection is needed to access it. this is not a problem in Netty (which also supports different protocols and transports).

Sources:

Java AMQP prototype (all meaningful changes are in RetriableWorkItem)
.NET Kestrel Web server metrics instrumentation that supports different protocols/transports

The trace with AMQP instrumentation:

Conclusion:

Attribute mapping to Sockets APIs in Java (EndPoint API in .NET) is reasonable
Determining network.transport could be tricky
Individual libraries may not expose socket-level data on the public surface, so populating attributes cannot be required.

Prototype network.peer/local.* semconv in a more esoteric networking instrumentation #373

Description