[OpenTelemetry.Extensions] Add baggage Activity processor

[MikeGoldsmith]

Fixes #1650

Changes

Adds component - baggage span processor.

For significant contributions please make sure you have completed the following items:

• Appropriate CHANGELOG.md updated for non-trivial changes
• Design discussion issue Request for new component: Baggage Span Processor #1650
• Changes in public API reviewed

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 5 lines in your changes are missing coverage. Please review.

Project coverage is 75.55%. Comparing base (71655ce) to head (d98d5a7).
Report is 220 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1659      +/-   ##
==========================================
+ Coverage   73.91%   75.55%   +1.64%     
==========================================
  Files         267      270       +3     
  Lines        9615    10256     +641     
==========================================
+ Hits         7107     7749     +642     
+ Misses       2508     2507       -1     

Flag	Coverage Δ
unittests-Exporter.Geneva	63.89% <ø> (?)
unittests-Exporter.OneCollector	89.72% <ø> (?)
unittests-Extensions	79.33% <0.00%> (?)
unittests-Instrumentation.AspNet	77.11% <ø> (?)
unittests-Instrumentation.EventCounters	76.36% <ø> (?)
unittests-Instrumentation.Owin	83.43% <ø> (?)
unittests-Instrumentation.Process	100.00% <ø> (?)
unittests-Instrumentation.Runtime	100.00% <ø> (?)
unittests-Instrumentation.SqlClient	90.90% <ø> (?)
unittests-Instrumentation.StackExchangeRedis	71.00% <ø> (?)
unittests-Instrumentation.Wcf	78.47% <ø> (?)
unittests-PersistentStorage	65.78% <ø> (?)
unittests-ResourceDetectors.Azure	81.53% <ø> (?)
unittests-ResourceDetectors.Host	54.11% <ø> (?)
unittests-ResourceDetectors.Process	100.00% <ø> (?)
unittests-ResourceDetectors.ProcessRuntime	76.08% <ø> (?)
unittests-Solution	80.17% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
...etry.Extensions/TracerProviderBuilderExtensions.cs	50.00% <0.00%> (-16.67%)	⬇️
...metry.Extensions/Trace/BaggageActivityProcessor.cs	0.00% <0.00%> (ø)

... and 228 files with indirect coverage changes

[MikeGoldsmith]

Thanks for the feedback @cijothomas - I'll make suggested changed over the next day or two.

[MikeGoldsmith]

@Kielek @cijothomas I've updated the PR to add the baggage span processor to the OpenTelemetry.Extensions package instead of creating a new one. Ready for another review 👍🏻

[MikeGoldsmith]

@cijothomas @Kielek updated as requested, let me know if you have any more feedback.

[cijothomas]

I think another important warning/note worth mentioning is that: This will likely result in duplicate information on multiple Activities. In the simplest case of an Activity for asp.net core request and one Activity for outgoing HttpClient call, the baggage information will be part of both these. It may be okay (or even desired), but depending on the backend/billing implications, it maybe not-so-desired.
A simple "Note:" here would be sufficient so users won't be surprised.

[MikeGoldsmith]

I don't think I understand. That's the intention of the baggage span processor; baggage entries are added to all subsequent Activities.

[cijothomas]

Looks good.
Left couple of non-blocking comments.

[martinjt]

I'd prefer if we had a constructor that allowed the user to add a prefix for baggage items that they'd like to add as attributes. We've had situations where customers have used a similar approach and managed to receive data from externally propagated baggage (accidentally).

A pattern like adding a prefix would mean that it becomes a lot more intentional, and therefore just a little safer.

[MikeGoldsmith]

I'd prefer if we had a constructor that allowed the user to add a prefix for baggage items that they'd like to add as attributes. We've had situations where customers have used a similar approach and managed to receive data from externally propagated baggage (accidentally).

A pattern like adding a prefix would mean that it becomes a lot more intentional, and therefore just a little safer.

I'd be happy to discuss this in a follow-up issue and/or PR. I'd prefer not to complicate the current PR as the suggested change is purely additive that someone can opt-in to using if desired.

[martinjt]

I'd prefer if we had a constructor that allowed the user to add a prefix for baggage items that they'd like to add as attributes. We've had situations where customers have used a similar approach and managed to receive data from externally propagated baggage (accidentally).
A pattern like adding a prefix would mean that it becomes a lot more intentional, and therefore just a little safer.

I'd be happy to discuss this in a follow-up issue and/or PR. I'd prefer not to complicate the current PR as the suggested change is purely additive that someone can opt-in to using if desired.

I think the fact that we're adding this to contrib gives this a bit more credibility, and therefore getting it right first time is more important. Putting this in as-is can lead to issues and therefore I think it's better to produce this in the way that makes it safest for customers.

[MikeGoldsmith]

I'd prefer if we had a constructor that allowed the user to add a prefix for baggage items that they'd like to add as attributes. We've had situations where customers have used a similar approach and managed to receive data from externally propagated baggage (accidentally).
A pattern like adding a prefix would mean that it becomes a lot more intentional, and therefore just a little safer.

I'd be happy to discuss this in a follow-up issue and/or PR. I'd prefer not to complicate the current PR as the suggested change is purely additive that someone can opt-in to using if desired.

I think the fact that we're adding this to contrib gives this a bit more credibility, and therefore getting it right first time is more important. Putting this in as-is can lead to issues and therefore I think it's better to produce this in the way that makes it safest for customers.

How would you like to see prefixes implemented, Include or exclude list? Should it handle whole matches or just prefixes? Both?

I don't think it's a simple answer and could get complicated quickly. This is the reason why I added warnings to both the README and class description but was asked to remove as it was deemed unnecessary.

I think adding something that's simple and clearly explains the pitfalls and chose to make incremental improvements is positive for this project. Attempting to make it perfect from outset is discouraging community participation. The saying of "perfection is the enemy of progress" could be true here.

[MikeGoldsmith]

PS we (Honeycomb) have opened PRs to contribute the same baggage span (activity) processor to a number of SDK contrib projects. I feel altering the behaviour of one could be disjointing for any organisation that uses multiple languages

• feat: Add baggage span processor opentelemetry-ruby-contrib#937
• feat: Add new baggage span processor package opentelemetry-js-contrib#2114
• processors/baggage: add baggage span processor opentelemetry-go-contrib#5404
• Add baggage span processor component opentelemetry-java-contrib#1290
• new(opentelemetry-processor-baggage): add new component opentelemetry-python-contrib#2436

[martinjt]

There's also the saying "Help people into the pit of success", which we're not doing here.

I'd say rushing this out is not the best option for that. We should workout the best approach, perhaps not in a PR, but an issue.

To me, adding a prefix is the best option.

I appreciate that this has been added for others, but that doesn't make it the right approach, just that there are more approaches that we've added. To be clear this has been an issue in the honeycomb distro's for a long time as you know.

[Kielek]

LGTM.

IMO, we can merge as is, but it will be great if you can find the agreement before we click the merge button. Either fix it here and/or create follow ups.

[MikeGoldsmith]

To be clear; adding sensitive data to baggage is not a good idea, regardless of using this processor. I don't disagree the security concern is real but don't think it's a problem with this processor. I think trace context should have a separate bucket of shared data that is separate from baggage.

@Kielek I've opened the following issue so we can continue the discussion outside of this PR:

• Baggage activity processor - key predicate #1695

[CodeBlanch]

@MikeGoldsmith Should we check Activity.IsAllDataRequested before adding the tags?

[cijothomas]

Not needed right? processors won't be called at all without that