clarify whether OTEL_TRACE_SAMPLER can contain a list

[brettmc]

What are you trying to achieve?

I'm trying to implement a new sampler, register it with an SDK, then enable & configure it via environment variables.

Additional context.

The OTEL_TRACES_SAMPLER section of the spec says the value holds "Sampler to be used for traces", and lists some known values which are either individual samplers or a combination (always_off, parentbased_always_on etc). In the PHP SDK, we've implemented it as an enumeration of known values since that's what all the examples look like.
However, the spec doesn't say that the field couldn't contain a list of samplers (parentbased,my_custom_sampler,always_on), which enables a couple of capabilities:

• custom/3rd-party samplers can be added to a registry and enabled
• samplers can be chained together in different ways without needing to enumerate all of them in the spec

So, I'd like to propose that the spec be adjusted:

• OTEL_TRACES_SAMPLER description to include "or list of samplers as a comma-separated list"
• list of known values to include "custom sampler name" and "or a comma-separated list of the above samplers"

[MrAlias]

The fact that this was not originally specified as a list seem intentional. How do you run multiple samplers for a single TracerProvider?

For more complex sampling configuration I recommend looking at the configuration file work: https://github.com/open-telemetry/opentelemetry-configuration

[brettmc]

How do you run multiple samplers for a single TracerProvider?

Samplers can already be composed in various ways - eg a parentbased_always_on sampler is actually a parent-based sampler and an always-on sampler.

In the use-case I have in mind, I want to be able to compose 3 samplers together, for example: parent-based, then attribute-based, then always-on/off. That does rely on those samplers being able to work together, eg always_on,always_off makes no sense...

For more complex sampling configuration I recommend looking at the configuration file work: https://github.com/open-telemetry/opentelemetry-configuration

I'm following this work, and I'm sure it will eventually solve this problem in a better way. Today, my SIG's implementation depends on env vars to configure everything for auto-instrumentation.

[trask]

@brettmc it would be great to get your feedback on open-telemetry/oteps#240