Handling of Conflicting Keys during Automatic Conversion from Zipkin Tags to OTEL Semantic Attributes

[making]

Feature

Handling of Conflicting Keys during Automatic Conversion from Zipkin Tags to OTEL Semantic Attributes

Rationale

Currently, the encoder automatically converts Zipkin tags to OTEL semantic attributes. However, this process does not account for situations where the resulting OTEL attribute key already exists within the original Zipkin tags. This can lead to conflicts or unintended overwriting of existing keys. Addressing this issue would provide greater control and prevent potential data inconsistencies, benefiting users who rely on precise attribute mapping during the conversion process.

Example Scenario

Consider a scenario where a Zipkin tag has a key that, when converted, results in an OTEL semantic attribute that matches an existing key in the original tags. This could cause the original data to be overwritten unintentionally. By either avoiding the conversion of existing keys or allowing users to configure whether or not these keys should be converted, the integrity of the data can be maintained.

[codefromthecrypt]

one thing to do is have a look at the otel collector codebase and if any defense is done there when they convert zipkin -> otel. maybe ping an author of that component for an opinion.