Feature/support activity source tags in zipkin exporter

[alimahboubi]

#5936
This pull request enhances the OpenTelemetry.Exporter.Zipkin implementation by refactoring the tag processing logic and adding comprehensive test coverage. The most notable changes include introducing methods to handle source and activity tags, improving the handling of special tags, and adding new unit tests to ensure correctness. Additionally, a utility class for creating ActivitySource instances was added to streamline test setup.

Refactoring and Enhancements:

• Refactored TagEnumerationState in ZipkinActivityConversionExtensions to include ProcessSourceTags and ProcessActivityTags methods for better separation of concerns and to handle source tags with a prefix (otel.scope). Null values are now skipped during processing. [1] [2]
• Introduced ProcessSpecialTag in TagEnumerationState to centralize logic for handling special tags like StatusCode, StatusDescription, and ZipkinErrorFlagTagName.

Test Coverage Improvements:

• Enhanced ZipkinActivityConversionExtensionsTests with new test cases to validate:
  • Processing of source tags with prefixes.
  • Ignoring null source tag values.
  • Handling of activity tags when source tags are absent.
  • Correct setting of special properties from source tags.
• Added a reusable ActivitySourceBuilder utility class to simplify the creation of ActivitySource instances in test scenarios.

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[rajkumar-rangaraj]

From #5936

The spec seems to say these attributes should be sent with span tags. But it doesn't specify how to handle collisions.

Activity tags were previously not added to Zipkin due to this issue. How did you resolve it? Does the spec provide guidance now?

[alimahboubi]

From #5936

The spec seems to say these attributes should be sent with span tags. But it doesn't specify how to handle collisions.

Activity tags were previously not added to Zipkin due to this issue. How did you resolve it? Does the spec provide guidance now?

@rajkumar-rangaraj Previously, only Activity tags were exported to Zipkin, while ActivitySource tags were not included. The spec does not provide explicit guidance on how to handle collisions for ActivitySource tags. According to the OpenTelemetry mapping spec, instrumentation scope tags should be exported as span tags, but no standard prefix is defined. To avoid collisions with span tags, I used the otel.scope. prefix for ActivitySource tags, which aligns with OpenTelemetry terminology and keeps them distinct. If the spec is updated with a recommended approach, we can adjust accordingly.

[Kielek]

From #5936

The spec seems to say these attributes should be sent with span tags. But it doesn't specify how to handle collisions.

Activity tags were previously not added to Zipkin due to this issue. How did you resolve it? Does the spec provide guidance now?

@rajkumar-rangaraj Previously, only Activity tags were exported to Zipkin, while ActivitySource tags were not included. The spec does not provide explicit guidance on how to handle collisions for ActivitySource tags. According to the OpenTelemetry mapping spec, instrumentation scope tags should be exported as span tags, but no standard prefix is defined. To avoid collisions with span tags, I used the otel.scope. prefix for ActivitySource tags, which aligns with OpenTelemetry terminology and keeps them distinct. If the spec is updated with a recommended approach, we can adjust accordingly.

Can you be proactive in this topic and create PR with some proposal/issue to discuss this?
Your proposal seems to be reasonable, but I would like to avoid breaking changes and handle it correctly.

[alimahboubi]

From #5936

The spec seems to say these attributes should be sent with span tags. But it doesn't specify how to handle collisions.

Activity tags were previously not added to Zipkin due to this issue. How did you resolve it? Does the spec provide guidance now?

@rajkumar-rangaraj Previously, only Activity tags were exported to Zipkin, while ActivitySource tags were not included. The spec does not provide explicit guidance on how to handle collisions for ActivitySource tags. According to the OpenTelemetry mapping spec, instrumentation scope tags should be exported as span tags, but no standard prefix is defined. To avoid collisions with span tags, I used the otel.scope. prefix for ActivitySource tags, which aligns with OpenTelemetry terminology and keeps them distinct. If the spec is updated with a recommended approach, we can adjust accordingly.

Can you be proactive in this topic and create PR with some proposal/issue to discuss this? Your proposal seems to be reasonable, but I would like to avoid breaking changes and handle it correctly.

Thank you for your feedback!

Regarding the discussion, there is already an open issue addressing this exact concern:
Zipkin transformation to support resource and instrumentation scope attributes (#4473).

This issue specifically discusses priority handling and collision resolution between tags added directly to an Activity (span attributes) and tags originating from the ActivitySource (instrumentation scope attributes). My current implementation follows a similar approach by clearly prefixing ActivitySource tags (otel.scope.), avoiding potential conflicts.

Additionally, note that the Console exporter already represents instrumentation scope tags separately,
Instrumentation scope (ActivitySource):
Name: test-web-application
Version: 1.0.0
Tags:
sample-source-tag: test
I'd be happy to further clarify or assist with updating documentation once a final consensus is reached on issue #4473.

[github-actions]

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or pushing will instruct the bot to automatically remove the label. This bot runs once per day.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.