Packaged alerts

[mikecote]

Could we add pre-packaged alerts to the packaging system? People can create alerts and rules as much as they want and share them. There has been questions about if alerting can integrate with EPM to allow users to share alerts. We'll use this issue to research and expand on that.

EPM: #36708

[elasticmachine]

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

[pmuellr]

I've been thinking of this as a set of alert param values and fill-in-the-blank values, targeted to specific alert types, for a specific package. Eg, for apache logs, there's probably a set of parameters that could be filled in automatically for a log alert, but there will also be values that the user will have to need to specify or customize.

I'm not sure where these would fit in the UI - it seems like a solution-specific thing, especially for alerts that are intended to be created in a solution.

Seems like alerting should handle the infrastructure part of this - getting these alert "templates", allowing solutions to find them, making it easy for them to create these alerts from the template.

If there aren't any customizable values, we could avoid using an existing alert editor to create these, a customer could "select" one and then have the alert created - I'm guessing there will almost always be some customization anyway.

Customers would still have to attach actions - I don't think these can be "templated".

I'm also hoping we can do this without having a notion of "preconfigured" alerts, as we still have issues getting a user and space associated with the alert. Seems like we can start with a "it's still a manual process, but easier than starting from scratch".

[pmuellr]

Customers would still have to attach actions - I don't think these can be "templated".

Something that could potentially help here, would be a way for an existing connector (or connectors) to be marked as "default" or "default for packaged alerts". We could then just add these to the alert directly without user interaction, but we would need to have all the action params filled in. Perhaps we'd just use this as a way to pre-populate the UI with these actions, but still require the user to "fill in the blanks" (eg, for email, setting the "to" addressee field).

[pmuellr]

Just had a brain fart, somewhat based on issue #50266 , which shares some similarities. Basically, how can we allow alerting resources to be recreated, when there are cases that a user needs to be involved to set API keys, etc.

Packaged alerts are kinda similar - perhaps - in that we'd like to make it easy to "import" alerts (not actions) from an elastic package, but since we won't know the alert param settings the customer wants, nor the actions they might want, we don't really want these "live". Hence my suggestion above regarding "templates".

In lieu of templates, it seems like we could arrange for packaged alerts to be "imported" from a package, but make them disabled upon creation. We'd need some defaults for alert parameters - maybe - in #50266 there is mention of allowing actions to be disabled which would also not run the validation on the params - perhaps we could do similar for alerts and leave the parms undefined. In any case, coming up with default values is probably not hard.

But the alert would be disabled, so a customer would need to enable it, which would then get the ownership set correctly (in case it was somehow automatically imported via the system). But it also wouldn't run immediately, with those "default" parameters, and give the customer a chance to set them as appropriate before enabling the alert.

To get an idea of how these packages work, see: https://github.com/elastic/integrations/tree/master/packages , and poke through one of those integrations you are familiar with - for me apache logs - and then look in the kibana directory.
Eg https://github.com/elastic/integrations/tree/master/packages/apache/kibana

You can imagine a new directory there alerts, which would have a number of alert SO templates in it, which we would then arrange to create actual alerts from.

[mikecote]

Moving from 7.x - Candidates to 8.x - Candidates (Backlog) after the latest 7.x planning session.

[YulNaumenko]

@arisonl we need a detail problem statement from you and marking this as blocked till that.