You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
## 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#524Closes#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.
Closeshoneycombio#524Closeshoneycombio#483
Is your feature request related to a problem? Please describe.
Related to this pollinators slack thread.
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.
The text was updated successfully, but these errors were encountered: