zipkin: Handle older semconv

[pellared]

Fixes #3793

Changes

Update OpenTelemetry to Zipkin Transformation to handle attributes from older semantic conventions in a backwards compatible way so that following attributes are (again) handled:

• net.peer.name
• net.host.name
• net.sock.peer.addr & net.sock.peer.port
• server.socket.domain
• server.socket.address & server.socket.port

The backwards compatibility of a stable OpenTelemetry to Zipkin Transformation was broken by:

• BREAKING: Replace net.peer.*/net.host.* with client.*/server.* (and source.*/destination.*) #3402
• Rename/replace (client|server).socket.(address|port) attributes with network.(peer|local).(address|port). #3713

[tigrannajaryan]

It is quite unfortunate that we referenced experimental semconv from a Stable doc. You are right that formal rules requires us to make changes to this Stable doc in a way that preserves backward compatibility.

At the same time it seems wrong to carry this duplicate information because we made a mistake in the past. I wonder if we have a way out here?

[pellared]

At the same time it seems wrong to carry this duplicate information because we made a mistake in the past. I wonder if we have a way out here?

I am not sure if it is really a "duplicate information". The intention is that Zipkin's remoteEndpoint is set if any of the listed attributes is present. The old versions are "ranked" below (have lower priority) than the attribute equivalents from newer semconv.

I think it may be even more important to handle the old semconv than peer.hostname and peer.address which is even "more legacy" (from OpenTracing). I guess the intention of the translation is to handle "as much as possible".

[tigrannajaryan]

I am not sure if it is really a "duplicate information". The intention is that Zipkin's remoteEndpoint is set if any of the listed attributes is present. The old versions are "ranked" below (have lower priority) than the attribute equivalents from newer semconv.

Nevermind. I didn't realize it is a ranked choice of one, not all of those.

[jsuereth]

LGTM pending @chalin's input on links and how that interacts with the website.

[carlosalberto]

Ping @chalin

[chalin]

Ping @chalin

I'm back! Looking at this now.

[chalin]

See inline for a new suggested pattern regex.

LGTM once the regex is updated per the comment.

[pellared]

@carlosalberto I think this PR is ready to be merged.

[carlosalberto]

Hey @Oberon00

As @trask mentioned, the note above the table should cover the case (as it actually covers all the listed values, e.g. peer.service, server.address, etc):

If Zipkin SpanKind resolves to either SpanKind.CLIENT or SpanKind.PRODUCER
then the service SHOULD specify remote endpoint otherwise Zipkin won't treat the
Span as a dependency.

Please fill an issue as a followup in case you think we should add details about this. Hope that's fine!