-
-
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
feat(alerts): ACI dual write helpers #81953
Conversation
Codecov ReportAttention: Patch coverage is ✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## master #81953 +/- ##
========================================
Coverage 80.42% 80.43%
========================================
Files 7300 7305 +5
Lines 321936 322196 +260
Branches 21015 21015
========================================
+ Hits 258931 259169 +238
- Misses 62600 62622 +22
Partials 405 405 |
ed3ff80
to
d447c15
Compare
condition=condition, | ||
comparison=alert_rule_trigger.alert_threshold, | ||
condition_result=condition_result, | ||
type=ConditionType.METRIC_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 added this but wasn't totally sure if we had other plans for the type
field
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 Conditions
enum right now, just haven't had a chance to link it to the type
's choices yet. I was thinking of renaming a couple of the fields on the data_condition cause they feel a bit confusing (but also dreading the migrations 🤣)
🤞 i get a bit more coding time today to tie up these loose ends.
return None | ||
|
||
data = { | ||
"type": alert_rule_trigger_action.type, |
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.
@saponifi3d we are adding the integration "provider" to the data blob here. my current plan is to not use this and deduce it via integration_id
and target_type
. i am still open to switching over and using this "type" if you think its a good idea for future work.
this might also make the UI portion of ACI a little easier since we will have a provider
that we can do filtering from 🤔
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.
the only problem with using this to search / do lookups on is that it's in the data
json blob, so those lookups will be reaaalllly slow compared to a column. I feel like there are more reasons for us to have this as a column than to keep the action this abstract though 🤔
maybe we just go back to ActionType.SLACK
, rather than a single type for all notifications? that way we could keep this model generally abstract, while making this property more accessible.
We could have a list of "notifications" like NOTIFICATION_ACTIONS=[ActionType.SLACK, ...]
and to trigger the generalized notification action, i can just check if the type is in that list instead of relying solely on the type.
would that work for y'all?
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.
if we split up the types per integration provider, would we still then have a split between "issue" and "metric" as we discussed yesterday?
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.
discussed in office hours: we will add a legacy field on an Action
for "issue" and "metric"
) | ||
threshold_type = alert_rule_trigger.alert_rule.threshold_type | ||
condition = ( | ||
Condition.GREATER if threshold_type == AlertRuleThresholdType.ABOVE else Condition.LESS |
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.
For UI purposes, do we need to include a case here for AlertRuleThresholdType.ABOVE_AND_BELOW
?
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.
Yes, good catch. I should reach out to design too and make sure the anomaly detection UI includes this (and anything else specific to 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.
I ended up leaving a note to add this for anomaly detection later on since adding Condition.ABOVE_OR_BELOW
includes creating the condition handler for anomaly detection which is a separate piece of work.
condition=condition, | ||
comparison=alert_rule_trigger.alert_threshold, | ||
condition_result=condition_result, | ||
type=ConditionType.METRIC_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'm using the Conditions
enum right now, just haven't had a chance to link it to the type
's choices yet. I was thinking of renaming a couple of the fields on the data_condition cause they feel a bit confusing (but also dreading the migrations 🤣)
🤞 i get a bit more coding time today to tie up these loose ends.
return None | ||
|
||
data = { | ||
"type": alert_rule_trigger_action.type, |
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.
the only problem with using this to search / do lookups on is that it's in the data
json blob, so those lookups will be reaaalllly slow compared to a column. I feel like there are more reasons for us to have this as a column than to keep the action this abstract though 🤔
maybe we just go back to ActionType.SLACK
, rather than a single type for all notifications? that way we could keep this model generally abstract, while making this property more accessible.
We could have a list of "notifications" like NOTIFICATION_ACTIONS=[ActionType.SLACK, ...]
and to trigger the generalized notification action, i can just check if the type is in that list instead of relying solely on the type.
would that work for y'all?
@@ -27,6 +31,7 @@ class Condition(StrEnum): | |||
LESS = "lt" | |||
NOT_EQUAL = "ne" | |||
GROUP_EVENT_ATTR_COMPARISON = "group_event_attr_comparison" | |||
ABOVE_AND_BELOW = "above_and_below" |
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.
you'll need to also register a method that can evaluate this. if it's all custom logic, take a look at the GROUP_EVENT_ATTR_COMPARISON
condition to get an example of how to register / use this.
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 took this out for now since we'll be adding special handling for the anomaly detection condition handler
b10ddac
to
8b337f9
Compare
) | ||
|
||
|
||
def migrate_alert_rule( |
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 really like how you re-structure this 💯
7ba8ac8
to
35b4991
Compare
35b4991
to
a11952b
Compare
This has gotten quite long 😓 I'll break it up tomorrow |
4804948
to
29219ba
Compare
A smaller chunk of #81953 that creates the helper methods to migrate the `AlertRule` and not the `AlertRuleTrigger` or `AlertRuleTriggerAction` just yet.
Add helper methods to create rows in the new ACI models that will be called just after creating the old models.