You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before we embark on an RFC with a proposal on how we might achieve this, I wanted to provide context about the problem I think we're facing with the existing alert framework.
Problem Statement
Currently, a rule type can create any action group it likes [1]. Rule Type A might do the following:
If condition 1 is true, schedule the "blue" action group
If condition 2 is true, schedule the "red" action group
If conditions 1 and 2 are both true, schedule the "purple" action group
If neither are true, schedule nothing
Whereas Rule Type B may do similar checks, but schedule entirely different groups (named "Info", "Warn", and "Critical", for example). For flexibility purposes, this is powerful.
In the rule management UI, Rule Type A might show up with something like this:
with the ability to set the various conditions or thresholds above this UI for each of the action group conditions.
[1] Is this true?
Question 1
How can a subset of rule types share a consistent action group experience?
This is important because we are considering allowing rule types to opt into a "no data" action group so that users can configure different action/connector set up to be triggered when the current rule encounters a lack of data when it expects data to evaluate.
Question 2
Given some answer to Question 1, how do we ensure those rule types can convert those action groups into alerts as data field values?
This is important because there is a desire to use action groups to power the idea of "alert severity", but without a way to ensure consistency between rule types, and to limit which action groups should be mapped to which AAD fields, this will become rather complicated and error-prone.
The text was updated successfully, but these errors were encountered:
Thanks for raising this! Way back, we realized the lack of consistency was going to be a problem, but we also didn't really have any experience to know what we should be doing here. Seems like we have some now!
This is important because we are considering allowing rule types to opt into a "no data" action group
We already have a "free" action group (any rule can use it) - recovered. "no data" has been on the radar for a while now, but I can't remember the issues surrounding it. And IIRC the "no data" discussions pre-date the need for the recovered action. Perhaps we were reticent to add "free" action groups at the time, when looking into "no data" or something. Seems like adding a new "free" action group - no data would be appropriate now.
Before we embark on an RFC with a proposal on how we might achieve this, I wanted to provide context about the problem I think we're facing with the existing alert framework.
Problem Statement
Currently, a rule type can create any action group it likes [1]. Rule Type A might do the following:
Whereas Rule Type B may do similar checks, but schedule entirely different groups (named "Info", "Warn", and "Critical", for example). For flexibility purposes, this is powerful.
In the rule management UI, Rule Type A might show up with something like this:
with the ability to set the various conditions or thresholds above this UI for each of the action group conditions.
[1] Is this true?
Question 1
How can a subset of rule types share a consistent action group experience?
This is important because we are considering allowing rule types to opt into a "no data" action group so that users can configure different action/connector set up to be triggered when the current rule encounters a lack of data when it expects data to evaluate.
Question 2
Given some answer to Question 1, how do we ensure those rule types can convert those action groups into alerts as data field values?
This is important because there is a desire to use action groups to power the idea of "alert severity", but without a way to ensure consistency between rule types, and to limit which action groups should be mapped to which AAD fields, this will become rather complicated and error-prone.
The text was updated successfully, but these errors were encountered: