-
Notifications
You must be signed in to change notification settings - Fork 94
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
feat(spans): Collect exclusive time for all spans #3268
feat(spans): Collect exclusive time for all spans #3268
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
To validate exclusive_time_condition
, could we add a test to ensure we don't emit more than one exclusive time metric for each span?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about exclusive_time_light
? Do we need the transaction tag for the metrics explorer? If yes, are there queries that would benefit from using exclusive_time_light
(fewer rows to scan)?
@jjbayer So the metrics explorer wants to expose the ability to surface samples for metrics including this span exclusive time metric. One of the main things we want to be able to support is to query all spans hence the motivation to extract this metric for all spans instead of known module spans. Now we want the transaction tag for the metrics explorer because it is likely one of the main ways for people to filter and narrow down the set of spans they want. To my understanding, the exclusive time light metric was specifically added as an optimization for the use cases where filtering on a transaction is not needed. There will be some queries that will benefit from using the exclusive time light metric so I will be raising this point to the team but we will still want this exclusive time metric for all spans. |
@Zylphrex alright, feel free to add it later in a follow-up PR! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See open question about duration_condition
.
(is_db.clone() | is_resource.clone() | is_mobile.clone() | is_http.clone()) | ||
& duration_condition.clone(), | ||
), | ||
condition: None, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we still apply duration_condition
here? Asking because even span_per_op
and spans_per_segment
apply the duration condition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we'd want to apply the duration condition here. We want to track absolutely all spans here and the condition was mainly created for a mobile specific use case.
We would like to start collecting the exclusive time for all spans while limiting cardinality by only tagging with low cardinality values. This is for @Zylphrex 's work with the metrics explorer.