A Sampling Configuration proposal

[PeterF778]

Presents a configuration model for describing built-in and third-party Samplers. This is written to support a class of future samplers, as described in the OTEP.

(description written by @jmacd)

[mtwo]

@carlosalberto @jack-berg can we mark this as triaged with priority p1?

[PeterF778]

Thank you all for your questions, comments and sharing your ideas. I'll work on a modification of this proposal and introduce a possibility to declare a sampler. I hope this will improve:

• readability, as the sampler arguments no longer will have to be purely positional
• applicability for non-Java platforms
• error checking and messaging

and will bring the proposal one step further to become a true meta-sampler.

[djaglowski]

Can we clarify that this proposal is for sampling traces only? Similarly, should the proposed configuration structs be nested under a traces section?

[PeterF778]

Can we clarify that this proposal is for sampling traces only? Similarly, should the proposed configuration structs be nested under a traces section?

Added the clarification. The proposal complements, but does not replace the file based configuration as defined by OTEP 225., so there's no need to specify traces.

[jack-berg]

@jmacd the goals of this should be compatible with what we're working on in the configuration group. Our working principle is to include all spec'd components as types in the configuration schema, but to ensure we support referencing / configuring custom extensions components, like samples, exporters, processors, propagators, metric readers, etc. This means that the schema directly specifies all the built-in samplers. In terms of configuring custom components, we're definitely still in the prototyping phase (here's a steel thread demo I've been using as a guiding use case in java) so we need to work out the details, but its a key feature we're committed to supporting.

IMO, a concrete task we can take out of this OTEP is for the sampling WG to work out the details of any required rule based samplers (I think I've also heard these called deterministic samplers) and add the definitions to the specification. After they're in the spec, the configuration SIG can add them to the schema.

[jmacd]

:tada: @PeterF778 this is looking great!

[jmacd]

@PeterF778 Would you say we can close this in favor of #250, or at least until there is progress with #250?

[PeterF778]

@PeterF778 Would you say we can close this in favor of #250, or at least until there is progress with #250?

Yes, we can close it, and revisit the ideas later.