Define resource reporting for Zipkin

[anuraaga]

Resource reporting for Zipkin is complicated due to there being no shared structs in the protocol, and that Zipkin instrumentation traditionally is very conservative. We can expect reporting resources without any filters in place to have a good chance of hurting deployments.

Temporary resource reporting removal: #1185

Related #823

[jmacd]

Note we have similar questions for Prometheus exporters: https://github.com/open-telemetry/opentelemetry-specification/pull/1185#issuecomment-726165151

[jonatan-ivanov]

My two cents: I think resource attributes should be added to Spans as tags. In order to avoid conflicts between span and resource attributes, I think it would worth considering adding a "namespace" prefix to those tags that are created from resource attributes, e.g. using one of the SDK resource attributes:

telemetry.sdk.language=java

could be added as a tag:

resource.telemetry.sdk.language=java

[breedx-splk]

In order to avoid conflicts between span and resource attributes,[...]

Are there actually any real-world examples of this conflict? I'm not opposed to this because it gives a little deeper insight on where the values originated from, but I'm not sure if there are actual conflicts right?

[jonatan-ivanov]

Maybe I should have said avoid possibility of conflicts. What I meant is not existing conflicts between semantic conventions but between semconv and user specified values. I'm not aware of any and not expecting to have any between semantic conventions (that should be fixed in semconv if it happens).

Also, this is just one way to do this, I think the question is: should OTel let the users add a span attribute that has the same key as a resource attribute.

If no: just documentation needed. If yes: prefix?

[hdost]

I believe this is related to https://github.com/open-telemetry/opentelemetry-rust/issues/1261