Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This proposes a path forward for open-telemetry/opentelemetry-specification#3205.
The idea is that implementers can come up with whatever attribute based scheme they want to use to samples spans. For example:
'myorg.log_level'
attribute in spans you want to sample and write a custom sampler that samples only above a certain level or samples a ratio of spans depending on the level.myorg.sample_rate
attribute and spans like in the test I added.There's a lot of use cases discussed but one in particular I find very useful is:
If you are processing tens (millions?) or "equivalent" chunks you may want to get some idea of long each chunk is taking but you probably don't want telemetry for every single chunk.
In the example above you'd get ~ 10
'processing chunk or whatever'
spans with their complete subtree (so 10'doing subtask in chunk'
).You could also sample nested loops e.g. to get 10% of the outer loop and 1% of the inner loop.
This won't "break" traces as discussed in the linked issue because any child spans will be of a non-sampled span will also be not sampled (assuming this is wrapped in the ParentBased Sampler).