[Alerting] Index Threshold doesn't support multiple Action Groups

[gmmorris]

Follow up from #82412.

Once the generic Conditions component is delivered by #82412, we want to use it to add Alert/Warning/Error thresholds to the Index Threshold Alert Type

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[pmuellr]

We need to decide how we want this to work. Let's say we have Alert / Warning / Critical as the action groups. Is everything the same with all these groups but the threshold values? We'll need to logic in the UI and server to ensure these logically make sense. For a comparator of >, presumably the threshold values would compare as Alert < Warning < Critical. Kinda thing. How would == work? :-)

Maybe we already decided on this, not sure. And I guess it depends on how #83278 goes. Does that issue also implicate how we'll store these things within the alert as well, or will we make every alert's UI adapt to how the server represents this?

I can't remember if we discussed whether we should have some "default" action groups like Alert / Warning / Critical that alerts can opt-in to, but could extend if it wanted to, as well as perhaps opt-out of just some of them (just support Alert / Warning). This would probably be a great thing to have, if it actually makes sense.

Last thought for the moment; our current action group for index threshold is "met threshold". Specifically designed to be generic / agnostic. I think it probably makes sense to do away with that one, so we'd only have Alert / Warning / Critical, but this means during a migration, any active index threshold alerts will see an action group change. I think we'll be ok if the old action group isn't available any more after the migration, certainly would be a good thing to test, if we remember.

[gmmorris]

Maybe we already decided on this, not sure. And I guess it depends on how #83278 goes. Does that issue also implicate how we'll store these things within the alert as well, or will we make every alert's UI adapt to how the server represents this?

Nope, totally up to the Alert Type - You can look at the example in Always Fires alert type in that PR.
The internal component used for each Action Group is totally up to the Alert Type and that type can decide how this data i stored, displayed etc.

All the #83278 PR does is provide a couple of reusable components that automatically render for each ActionGroup that has had conditions configured (supplied by the AlertType implementor) and pickers for selecting additional ActionGroups to configure.

It's designed to be as open as possible because being too restrictive makes it more likely implementors will avoid using it.
I recommend catching up on the recording from our sync on this from 2020-11-12.

[Shangguan]

It would be really great if Kibana users could define their own action groups in the UI pop-up (or via REST api once that is available), exactly as shown in the screenshot above for Index Threshold alert type, and for the Search DSL Alert type (that is going to be available soon).

Speaking on behalf of a customer - they would love the ability to define custom action groups and associate different actions per group. A good example is CPU Usage:

• Minor action group: 50% - 70% of CPU Utilization, action of logging + email
• Major action group: 70% - 80%, action of ServiceNow + Slack
• Critical action group: 80% beyond, action of ServiceNow + PagerDuty + JIRA + Email + Slack

Numbers are contrived but you should get the idea...

[ymao1]

Closing due to lack of interest.