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

Apply sample rates based on span count #483

Closed
puckpuck opened this issue Jul 29, 2022 · 0 comments · Fixed by #532
Closed

Apply sample rates based on span count #483

puckpuck opened this issue Jul 29, 2022 · 0 comments · Fixed by #532
Labels
type: enhancement New feature or request

Comments

@puckpuck
Copy link
Contributor

Is your feature request related to a problem? Please describe.
Related to this pollinators slack thread.

It would be really cool if we could...weight traces by how many spans they have rather than using span length as a key in refinery. Like, if a trace has over 1k spans, it now counts as if it were two traces for determining sample rate.
I bring this up because we have some just-infrequent enough web requests to not get sampled by Refinery that are...sadly a couple thousand spans and it'd be nice to be able to force refinery's hand a bit there.

Describe the solution you'd like
A way to specify a sample rate based on the # of spans in a trace.

Additional context
A special type of rule or rule condition could be created based on the # of spans in the trace. Rule scope would affect how this would get evaluated.

@puckpuck puckpuck added the type: enhancement New feature or request label Jul 29, 2022
kentquirk added a commit that referenced this issue Oct 6, 2022
## Which problem is this PR solving?

Adds the ability to add the trace's span count to the root span of the
trace, and does it in a way that allows the rules engine to query it as
`meta.span_count`. This would allow rules that depend on span count --
for example, a rule that adjusts sample rate so that larger traces are
kept less often.

Note that this value is not available if the root span hasn't arrived
when the TraceTimeout completes; at this point, the rules will be
evaluated without a `span_count` because there is no root span to put it
on.

If the root span arrives late, it will be updated with the total number
of spans that have arrived at that point, so that the value stored in
Honeycomb is close to correct. If more spans arrive later, they will not
update the value in the root span.

Closes #524  
Closes #483
ghost pushed a commit to opsramp/tracing-proxy that referenced this issue Jul 5, 2024
## Which problem is this PR solving?

Adds the ability to add the trace's span count to the root span of the
trace, and does it in a way that allows the rules engine to query it as
`meta.span_count`. This would allow rules that depend on span count --
for example, a rule that adjusts sample rate so that larger traces are
kept less often.

Note that this value is not available if the root span hasn't arrived
when the TraceTimeout completes; at this point, the rules will be
evaluated without a `span_count` because there is no root span to put it
on.

If the root span arrives late, it will be updated with the total number
of spans that have arrived at that point, so that the value stored in
Honeycomb is close to correct. If more spans arrive later, they will not
update the value in the root span.

Closes honeycombio#524  
Closes honeycombio#483
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant