-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
feat(tracemetrics): Parse metric from aggregations #103102
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
Conversation
This parses the metric from aggregations instead of relying on the top level metric name/type. The top level ones still take precendence for better compatibility. It has the limitation that it only allows a single metric across all the aggregations.
| ) | ||
| selected_metrics.add(metric) | ||
|
|
||
| if not selected_metrics: |
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.
Bug: Equations Ignore Metric Aggregations
The _extra_conditions_from_columns method accepts an equations parameter but never processes it. When metric aggregates like sum(value,foo,counter,-) are used inside equations, the metric information won't be extracted, causing the query to miss the required metric filter conditions. This breaks the feature's core functionality of parsing metrics from aggregations when they appear in equations.
❌ 6 Tests Failed:
View the top 3 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
| equations: list[str] | None, | ||
| ) -> TraceItemFilter | None: | ||
| # use the metric from the config first if it exists | ||
| if extra_conditions := self._extra_conditions_from_metric(search_resolver): |
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.
This config is populated from the extra request params right? Is the long term plan to eventually stop supporting it?
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.
Correct. Trace metrics uses it own TraceMetricsSearchResolverConfig that inherits from SearchResolverConfig. This currently has top level configs to specify 1 metric. Long term, we'll remove that and only rely on the metric specified in the aggregation.
| if len(selected_metrics) > 1: | ||
| raise InvalidSearchQuery("Cannot aggregate multiple metrics in 1 query.") |
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.
two questions
- if you can't select multiple metrics in one query why do we need it in the aggregates?
- shouldn't we dedupe the selected_metrics list if there's multiple aggregates on the same metric?
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.
- We cant select multiple metrics today because EAP does not have support to allow us to express it yet. See EAP-313
selected_metricsis a set of tuples so it already dedupes, meaning it lets you select multiple aggregates on the same metric
Issues attributed to commits in this pull requestThis pull request was merged and Sentry observed the following issues: |
This parses the metric from aggregations instead of relying on the top level metric name/type. The top level ones still take precedence for better compatibility. It has the limitation that it only allows a single metric across all the aggregations.
Same as #103102 but for formulas so per_second and per_minute will work as well.
Same as #103102 but for formulas so per_second and per_minute will work as well.
This parses the metric from aggregations instead of relying on the top level metric name/type. The top level ones still take precedence for better compatibility. It has the limitation that it only allows a single metric across all the aggregations.