feat(alerts): ACI dual write alert rule helpers #82400
Conversation
github-actions
bot
added
the
Scope: Backend
Codecov ReportAttention: Patch coverage is ✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## master #82400 +/- ##
===========================================
+ Coverage 55.70% 80.43% +24.73%
===========================================
Files 6168 7307 +1139
Lines 257140 322167 +65027
Branches 21011 21011
===========================================
+ Hits 143231 259129 +115898
+ Misses 113504 62633 -50871
Partials 405 405 |
|
|
||
|
|
||
| def create_data_source( | ||
| organization_id: int, snuba_query: SnubaQuery | None = None |
There was a problem hiding this comment.
seems weird but appears to be to appease typing
| self.metric_alert = self.create_alert_rule() | ||
| self.rpc_user = user_service.get_user(user_id=self.user.id) | ||
|
|
||
| def test_create_metric_alert(self): |
There was a problem hiding this comment.
would it be possible to test the resulting models in workflow engine like process_workflow_engine? doesn't have to be in this PR
| detector_workflow = DetectorWorkflow.objects.get(detector=detector) | ||
| assert detector_workflow.workflow == workflow | ||
|
|
||
| workflow_data_condition_group = WorkflowDataConditionGroup.objects.get(workflow=workflow) |
There was a problem hiding this comment.
i think the when condition group doesn't need to exist in WorkflowDataConditionGroup, it's already attached to the workflow via workflow.when_condition_group. i believe this model is used for the IF condition groups
A smaller chunk of #81953 that creates the helper methods to migrate the `AlertRule` and not the `AlertRuleTrigger` or `AlertRuleTriggerAction` just yet.
|
|
||
| def create_data_condition_group(organization_id: int) -> DataConditionGroup: | ||
| return DataConditionGroup.objects.create( | ||
| logic_type=DataConditionGroup.Type.ANY, |
There was a problem hiding this comment.
nit: no need to set this since it's the default.
| data_condition_group = create_data_condition_group(organization_id) | ||
| workflow = create_workflow(alert_rule.name, organization_id, data_condition_group, user) | ||
| detector = create_detector(alert_rule, project.id, data_condition_group, user) |
There was a problem hiding this comment.
You'll want to create many data condition groups here instead.
the first is for the detector, on the workflow_condition_group. This condition group generates state changes for the workflow to respond to.
Looking at a specific example...
In this image, is the Detector.workflow_condition_group. In this DataConditionGroup, we're configuring two DataConditions;
- if 300 > {metric} then return Critical
- if 300 <= {metric} then return OK
When the data is evaluated, a DetectorState object is created for the state change. That state is then passed back to process_detectors where the issue occurrence is created.
For the workflow data condition group(s) we'll have a few. The first one, workflow.when_condition_group is Null. This is Null, because we always want to evaluate a detector state change events.
Next, we'll want to create data condition groups for the actions for the metric alert (and eventually detector)
Each of these rows is a new Data Condition Group, so two groups in this screenshot.
Looking at the first row, the Data Condition would be the priority level; "critical status". This is allows us to check if the detectors state change (which is stored as an issue occurrence). if the state makes that change, then we'll trigger the associated action (send email to me).
In the processor, it will continue to evaluate all those conditions generating a list of actions to trigger based on the data condition groups associated action.
A smaller chunk of #81953 that creates the helper methods to migrate the
AlertRuleand not theAlertRuleTriggerorAlertRuleTriggerActionjust yet.