[Alerts][Actions] Support dedicated context per action group

[darnautov]

Describe the feature:
The alerting framework allows providing context variables per action group.

Describe a specific use case for the feature:
In the Anomaly detection alert type it's possible that selected anomaly detection jobs encountered some issues, e.g. datafeed has been stopped for some reason. In such a scenario we should notify the user. According to the Alerting framework logic, we should create an action group for this case, let's call it Datafeed has been stopped. But this action group would have different context variables. In particular, all anomaly result data is not available, and instead, the job id and the timestamp of when the datafeed has been stopped are provided. Currently, the Recovered action group hides the context variables, so I expected it to be possible for the custom actions group to have dedicated context.

Alternative solution

Alerting framework allows notifying the user about an error state in the alert. In that case, the user can select Run when - Error occurred (should be a built-in action group, similar to the Recover). And it should probably have error.message variable.

[pmuellr]

We still need to do something about a "NO DATA" status - perhaps this would work in this case? I think we'd need to provide some way for an alert type to provide a message providing a description of what happened.

see issue #67296

[darnautov]

@pmuellr it might work, but it would require the user to explicitly configure an action for this alert status, wouldn't it? Is it going to be another built-in action group then, i.e. Recovered and No data?

[pmuellr]

Is it going to be another built-in action group then, i.e. Recovered and No data?

It is certainly something like that - probably a new "status" value, and a corresponding built-in action group. Each alert type would have to make it's own determination of "no data" ... eg, for the index threshold, it could be that no index was found, or that the no documents were found for the specified query.

[elasticmachine]

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

[mikecote]

We are planning to move towards a common context (schema) per alert across all rule types. We may need to dig into the use case here to make sure we can move towards a common schema. cc @kobelb

[pmuellr]

As we're currently redesigning how context variables work, we'll keep this in mind, but probably eventually close as we'll have a different architecture.

[ymao1]

cc @shanisagiv1

[mikecote]

@darnautov would the transition to alerts as data help with the request? is the request still relevant?

[darnautov]

@mikecote I guess it's not relevant anymore, as we introduced the Anomaly detection jobs health rule in #106084

[mikecote]

Ok sounds good, thank you for confirming. We came across this issue during our last backlog refinement session. We'll go ahead and close this. 🙏