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.
Comes from a big trace problem where there's something valuable buried in a 100k+ span trace. Generally users want to drop these, but occasionally they come through via keep-error rules and the like
Describe the solution you'd like
Instead of having only drop or sample options for ?.NUM_DESCENDANTS rules (or any rule I guess) it'd be cool to have a keep_essentials option. For example
This would preserve the span or span event(s) where an error exists, plus their parent/ancestor spans up to the root span. This way the user would get the spans that matter from their giant trace, and be able to identify through the parent spans where in the process the damage occurred, but would not get 100k events against their honeycomb budget.
I think from their, you could also put the trace_id into the drop decision cache, so if it's a long running batch process you don't get stuff after the decision is made.
Describe alternatives you've considered
¯\_(ツ)_/¯
Additional context
No real additional concept, just liked the idea spawned by some customer questions.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Comes from a big trace problem where there's something valuable buried in a 100k+ span trace. Generally users want to drop these, but occasionally they come through via keep-error rules and the like
Describe the solution you'd like
Instead of having only drop or sample options for
?.NUM_DESCENDANTS
rules (or any rule I guess) it'd be cool to have a keep_essentials option. For exampleThis would preserve the span or span event(s) where an error exists, plus their parent/ancestor spans up to the root span. This way the user would get the spans that matter from their giant trace, and be able to identify through the parent spans where in the process the damage occurred, but would not get 100k events against their honeycomb budget.
I think from their, you could also put the trace_id into the drop decision cache, so if it's a long running batch process you don't get stuff after the decision is made.
Describe alternatives you've considered
¯\_(ツ)_/¯
Additional context
No real additional concept, just liked the idea spawned by some customer questions.
The text was updated successfully, but these errors were encountered: