-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
ref(alerts): Update Snuba queries to match events-stats more closely #77755
ref(alerts): Update Snuba queries to match events-stats more closely #77755
Conversation
@@ -42,6 +42,27 @@ | |||
from sentry.utils.snuba import MAX_FIELDS, SnubaTSResult | |||
|
|||
|
|||
def get_query_columns(columns, rollup): |
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 moved this to be reused by anomaly detection
""" | ||
serializer = SnubaTSResultSerializer(organization=organization, lookup=None, user=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.
I'm using the same serializer the events-stats
endpoint uses and just pulling that data off to format into a list of TimeSeriesPoint
s for Seer's API. I clicked through every alert type and it always has the timestamp and count
data, | ||
resolve_axis_column(query_columns[0]), | ||
allow_partial_buckets=False, | ||
zerofill_results=False, |
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 was getting strange results in tests with this set to True, and for our purposes I think it doesn't matter that much since we default to sending Seer a 0 if we don't find a count anyway
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.
By "strange" I mean it was hitting this line and overwriting data with a count I had in a test as an empty array.
Codecov ReportAttention: Patch coverage is ✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## master #77755 +/- ##
==========================================
+ Coverage 78.09% 78.10% +0.01%
==========================================
Files 6979 6988 +9
Lines 309710 310197 +487
Branches 50695 50744 +49
==========================================
+ Hits 241857 242291 +434
- Misses 61378 61420 +42
- Partials 6475 6486 +11 |
634ed2c
to
4dfe836
Compare
stats_period=None, | ||
environments=environments, | ||
) | ||
snuba_query_string = get_snuba_query_string(snuba_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.
This is one of the key changes here - the front end constructs a stringified query based on snuba_query.query
AND snuba_query.event_types
. This adds a join to the table for things like errors count with the is:unresolved
query, or when you're using the dropdown to select "errors", "default", or "errors OR default" event types
The users experiencing errors query is selecting data as a different name but it's otherwise the same, I don't know if that makes a difference to the outcome?
anomaly detection: |
if dataset_label == "events": | ||
# DATASET_OPTIONS expects the name 'errors' | ||
dataset_label = "errors" | ||
elif dataset_label == "generic_metrics": | ||
# XXX: performance alerts in prod | ||
dataset_label = "transactions" |
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.
not sure if I need to be using the discover dataset here, it's hard to know since it's different locally
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 think we do want to use the discover dataset - unfortunately this differs in prod vs. locally so it's confusing but locally we make this request:
api/0/organizations/sentry/events-stats/?interval=60m&project=1&query=event.type%3Atransaction&referrer=api.organization-event-stats&statsPeriod=9998m&yAxis=count%28%29
and in prod we make this request:
api/0/organizations/sentry/events-stats/?dataset=metricsEnhanced&interval=60m&project=1&query=event.type%3Atransaction&referrer=api.organization-event-stats&statsPeriod=9998m&yAxis=count%28%29
the events-stats
endpoint gets the dataset label from the request here and falls back to using discover if nothing is passed (like in production).
In our case we're not getting the dataset label from the request but rather the snuba query object, so instead of it being "discover" it's "generic_metrics" in production and "transactions" in my local db.
All that to say for performance metrics alerts we need to use the discover dataset for both generic_metrics
and transaction
dataset labels
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! I just had some nitpicks - may want to have someone with more insights into seer take another glance too.
|
||
if dataset == metrics_performance: | ||
nested_data = data.data.get("data", []) |
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.
so, this is... data.data.data
? 😅 is there anywhere we have control over any of those that we could rename the variable? i think adding context like what kind of data it is would help a lot.
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.
Sadly no, this is the format of SnubaTSResult
which is typed in the function signature.
tests/sentry/incidents/endpoints/test_organization_alert_rule_anomalies.py
Show resolved
Hide resolved
…77755) When a user creates an anomaly detection alert we need to query snuba for 28 days worth of historical data to send to Seer to calculate the anomalies. Originally (#74614) I'd tried to pull out the relevant parts of the `events-stats` endpoint to mimic the data we see populated in metric alert preview charts (but for a larger time period, and it's happening after the rule is saved so I can't use any of the `request` object stuff) but I think I missed some things, so this PR aims to make that data be the same. Closes https://getsentry.atlassian.net/browse/ALRT-288 (hopefully)
When a user creates an anomaly detection alert we need to query snuba for 28 days worth of historical data to send to Seer to calculate the anomalies. Originally (#74614) I'd tried to pull out the relevant parts of the
events-stats
endpoint to mimic the data we see populated in metric alert preview charts (but for a larger time period, and it's happening after the rule is saved so I can't use any of therequest
object stuff) but I think I missed some things, so this PR aims to make that data be the same.Closes https://getsentry.atlassian.net/browse/ALRT-288 (hopefully)