Tweak rule based sampler#461
Conversation
| - array | ||
| - 'null' | ||
| type: array | ||
| minItems: 1 |
There was a problem hiding this comment.
Noticed this while implementing and seeing formatting look weird in schema-docs.md
.rules is not required, but if it is present, it should be non null and have at least 1 item.
There was a problem hiding this comment.
Initially I thought it could be fine to allow empty rules, for example if the config is programatically generated based on something else but ends up with []. Of course, such a generator could be sophisticated enough to swap in always_off for such a scenario so ok with either way.
There was a problem hiding this comment.
Of course, such a generator could be sophisticated enough to swap in always_off
Exactly. Given that we can always loosen constraints but not add them, I'd rather start stricter and loosen in response to feedback.
| The rules for the sampler, matched in order. | ||
| Each rule can have multiple match conditions. All conditions must match for the rule to match. | ||
| If no conditions are specified, the rule matches all spans that reach it. | ||
| If no rules match, the span is not sampled. |
There was a problem hiding this comment.
This is documented in kitchen-sink.yaml but this behavior is important to both implementers and users and so should be part of the schema via description.
| } | ||
| } | ||
| }, | ||
| "ExperimentalComposableRuleBasedSamplerRule": { |
There was a problem hiding this comment.
Thanks for the help @jack-berg! I agree with your open-telemetry/opentelemetry-java#7861 (comment) missed that case when reasoning out the use cases. Should we have a predicates array of these that are ANDed?
|
@open-telemetry/configuration-approvers can I get a quick review from someone on this? Should be uncontroversial. |
3 participants
Nothing important for rc3.