Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass span id to Sampler #3574

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

adriangb
Copy link
Contributor

@adriangb adriangb commented Dec 8, 2023

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:

  • Log level equivalent. Put a '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.
  • Sample rate at the span level. Put a 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:

for x in range(100):
    with tracer.start_as_current_span('processing chunk or whatever', attributes={'sample_rate': 0.1}):
        x = 1 + 1 - 1
        with tracer.start_as_current_span('doing subtask in chunk'):
              sleep(x)

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).

@adriangb adriangb requested a review from a team December 8, 2023 09:25
@ocelotl
Copy link
Contributor

ocelotl commented Jan 5, 2024

This is a request for a feature that has not yet been approved by the spec. I don't have anything against it but I'm marking this PR as a draft to prevent accidental merging. This PR can remain open so that @adriangb can use it to explain this idea to the spec.

@ocelotl ocelotl marked this pull request as draft January 5, 2024 19:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants