Add experimental composite samplers

[anuraaga]

This adds the contrib composite samplers to EDOT. There is interest from @AlexanderWert and others in being able to check sampling + representative count behavior end-to-end with EDOT, so sending this PR. One issue is there aren't any official env vars for it yet, so I prefaced with experimental_composite_ to be able to use them initially. In the long term, the SDK will probably switch the samplers transparently to the new ones at which point they can be deprecated / removed.

Let me know what you think of the approach - whatever we decide on we would want to apply to other languages in the same way as the sampler implementations become available.

[SylvainJuge]

I think for now we depend on knowing what are the upstream implementation choices for this, so I would suggest that we make this a draft PR so we don't merge it yet.

To me there are a few questions that we need to answer before merging this:

• what is the configuration option for this ?f
• what is the general strategy to implement this upstream in the agent itself (and not only in a contrib component).
• how to it with runtime configuration ? From what I understand from the still-in-progress spec we can't set the sampling rate to zero by just changing sampling rate, so we might have to switch to "always-on" or "always-off" samplers to implement zero or 100% sample rate.

[anuraaga]

Thanks @SylvainJuge - I think one general point is deciding whether we support experimenting on new features before upstream is clear on them in EDOT, and if so how we do it. I think it can be hard to provide feedback upstream without having a system in place for it, but at the same time it can cause some confusion for users so needs a general product decision I guess. @AlexanderWert for any thoughts.

what is the configuration option for this ?f

There isn't any configuration being discussed yet - as far as I know, the desire is to transparently swap the existing implementations with the new ones. In reality, there may be pushback and eventually configuration options are provided but I expect this to take a few months to settle down.

what is the general strategy to implement this upstream in the agent itself (and not only in a contrib component).

I have a PR to implement it in SDK which will allow the upstream agent to adopt it, but given the idea of transparently swapping I don't think they would add it until that is decided.

open-telemetry/opentelemetry-java#7626

how to it with runtime configuration ? From what I understand from the still-in-progress spec we can't set the sampling rate to zero by just changing sampling rate

While the spec suggests returning different instances for 0%, it's awkward for the user so currently during implementation we are leaning towards not taking that approach. But either way, it would be on the implementation side rather than configuration side to take care of it since it wouldn't be specific to env var instantantiation.

open-telemetry/opentelemetry-js#5839 (comment)

I'd lean towards not changing this PR to draft, I think we can decide on whether we should close it or not instead based on the approach to take

• Don't add future functionality experimentally to EDOT - close PR and wait for SDK to finish things up
• Allow adding it but wait for the SDK incubator rather than using contrib - close PR and open new one in 1-2 months when the SDK implementation is ready
• Go with the contrib implementations which will mostly match SDK - keep the PR open with the intent of merging it

I think either of these is fine and just depends on the goals - except for SDK vs contrib timing decision, it would apply to all the languages, not just Java.

[jackshirazi]

We don't need all these samplers. We want specifically the ConsistentSampler.parentBased(ConsistentSampler.updateableProbabilityBased) from consistent56, which we'll make our default sampler. I don't see the need for any of the others until they've been moved into the core.

The approach looks fine, can you adjust so that we just have those two?

[jackshirazi]

Thanks, I tested it hooked up to the central config and it works fine. Thank you for the contribution and your patience!