Skip to content
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

Closed
wants to merge 27 commits into from

Conversation

ceorourke
Copy link
Member

Add helper methods to create rows in the new ACI models that will be called just after creating the old models.

@github-actions github-actions bot added the Scope: Backend Automatically applied to PRs that change backend components label Dec 11, 2024
Copy link

codecov bot commented Dec 11, 2024

Codecov Report

Attention: Patch coverage is 90.21739% with 9 lines in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
...ry/workflow_engine/migration_helpers/alert_rule.py 89.77% 9 Missing ⚠️
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            

condition=condition,
comparison=alert_rule_trigger.alert_threshold,
condition_result=condition_result,
type=ConditionType.METRIC_CONDITION,
Copy link
Member Author

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

Copy link
Contributor

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,
Copy link
Member

@iamrajjoshi iamrajjoshi Dec 12, 2024

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 🤔

Copy link
Contributor

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?

Copy link
Member

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?

Copy link
Member

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
Copy link
Contributor

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?

Copy link
Member Author

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).

Copy link
Member Author

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.

src/sentry/workflow_engine/metric_helpers.py Outdated Show resolved Hide resolved
condition=condition,
comparison=alert_rule_trigger.alert_threshold,
condition_result=condition_result,
type=ConditionType.METRIC_CONDITION,
Copy link
Contributor

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.

src/sentry/workflow_engine/metric_helpers.py Outdated Show resolved Hide resolved
src/sentry/workflow_engine/metric_helpers.py Outdated Show resolved Hide resolved
return None

data = {
"type": alert_rule_trigger_action.type,
Copy link
Contributor

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"
Copy link
Contributor

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.

Copy link
Member Author

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

tests/sentry/workflow_engine/test_metric_helpers.py Outdated Show resolved Hide resolved
src/sentry/workflow_engine/metric_helpers.py Outdated Show resolved Hide resolved
src/sentry/workflow_engine/types.py Outdated Show resolved Hide resolved
src/sentry/workflow_engine/models/data_condition.py Outdated Show resolved Hide resolved
src/sentry/workflow_engine/types.py Outdated Show resolved Hide resolved
)


def migrate_alert_rule(
Copy link
Contributor

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 💯

@ceorourke ceorourke force-pushed the ceorourke/aci-dual-write-helpers branch from 35b4991 to a11952b Compare December 19, 2024 00:43
@ceorourke
Copy link
Member Author

This has gotten quite long 😓 I'll break it up tomorrow

@ceorourke ceorourke force-pushed the ceorourke/aci-dual-write-helpers branch from 4804948 to 29219ba Compare December 19, 2024 19:21
ceorourke added a commit that referenced this pull request Dec 20, 2024
A smaller chunk of #81953 that
creates the helper methods to migrate the `AlertRule` and not the
`AlertRuleTrigger` or `AlertRuleTriggerAction` just yet.
@ceorourke
Copy link
Member Author

Closing in favor of #82400 and #82492

@ceorourke ceorourke closed this Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Scope: Backend Automatically applied to PRs that change backend components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants