[Discover] Enable threshold alerts

[timroes]

We want to enable threshold alerts in Discover. Those should be able to take a configured search (filter/query) in Discover and allow to setup an alert that will trigger if the value of found documents is above or below a configured threshold.

We want to approach the implementation in 3 phases:

• Phase 1 - Simple POC that allows configuring an alert and see that alerting triggered ([Discover] POC to add Alerting to Discover #117830)
• Phase 2 - Technical RFC including the alerting team and the app services team
• Phase 3 - Implementing MVP

Phase 1 - POC

It's done, here's the POC #117830

Phase 2 - RFC

To enable the creation of an alert rule in Discover we will extend the given Elasticsearch query rule. This rule will be extended by the use of searchSource for data fetching (This means it's using data view, query, and filters). It allows us to link back to Discover, showing the document that triggered the alert notification. The alert rule can’t be edited in Discover, but in Stack management. In the MVP it’s not possible to edit searchSource parameters (data view, query, filter) once they are displayed in the flyout, due to the complexity of implementing filter editing in the user interface. This for sure should be provided in a follow up iteration.

Alert rule parameters

We will extend the Elasticsearch query rule by 2 parameters

1. searchType - it determines which type of search should be used, the available types are
   • esQuery - which is the default,
   • searchSource - when it's created in Discover
2. searchConfiguration - it ´contains the serialized search source fields (data_view, query, filters) that are used to fetch the documents from Elasticsearch. For searchSource we need to take persistable state migrations into consideration.

UI in Discover

There will be a new top navigation link, called "Alerts". This should open a popover containing 2 links

1. Create threshold rule
   • This link should open a flyout allowing the user to create the Elasticsearch query rule with searchSource parameters
2. Manage rules and connectors
   • This link should open the Rules and connectors page of Stack management

When the user selects Create threshold rule, a searchSource object containing the current data view, query, and filters is serialized and used to initialize the flyout containing the form to create the rule. Editing those parameters in the background is no longer propagated to the flyout. There’s also no link to a saved search stored. Of the original Elasticsearch query rule the selection of INDEX and Elasticsearch query should not be displayed in the UI since they are not needed. Once opening the flyout, the user cannot edit Data View, Query, Filter. With a click on “Save” the new rule is persisted, and can be viewed in “Stack Management / Rules and Connectors”.

UI in Stack Management

In Stack Management / Rules and Connectors users can view and edit the rule (but not data view, query and filters). When showing the details page of the rule, the “View in app” link should link back to Discover using the query, filters, data view of the rule in the current time range (when searchType is searchSource).

An Elasticsearch query rule of searchType esQuery should look like before.

Server side: Alert rule executor

The rule alert executor needs to be extended to also work with searchSource.

• It uses the serialized fields of the persisted searchSource to construct a searchSource object
• It adds a date_range filter constructed by the configured timeWindowSize and timeWindowUnit
• It's used to fetch the number of matching documents from Elasticsearch, also a number of matching documents configured by size.
• The number of matching documents is compared to the configured threshold
• If the threshold is met, the actions are scheduled, the user will be notified depending on the configuration.

Linking back to Discover

If the rule was based on searchSource, users could add a link to Discover, in the other case for the esQuery rule type it should link to the rule details page.

Internally the link contains the ruleId, the absolute time range (from, to) and a checksum of the actual rule configuration (searchSource + threshold settings). It will look like this:

{publicUrlOfDiscover}#/viewAlert/{$ruleId}?from={$from}&to={$to}&checksum={$checksum}

We will add a new route to the Discover plugin that’s taking care of handling this link.

This route fetches the rule by ruleId. The checksum is used to determine if there were changes in the meantime. The viewAlert route would use the rule’s configuration and the given time range to forward to the main view that should show the documents that triggered the alert notification. In the case the checksum indicates that the rule params has been changed, there should be a warning displayed that the documents displayed might not match the documents triggering the notification since there have been changes to the rule configuration in the meantime.
If the checksum matches a different notification should be displayed, because the displayed documents might also be different to the documents that triggered the alert due to more ingested, indexed or deleted documents

Phase 3 - Implementation

#124534

Phase 4 - Add editing capability

Note: As of March 23, the likely plan is to ship V1 in 8.3 where we also discussed addressing the lack of support for editing.

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[timroes]

@ryankeairns @andreadelrio I've just talked to @Alex3k and when talking about the "linked vs. non-linked to saved search" discussion we had, he suggested we should try to make it clear to users that the alert will not be linked to the saved search and updating the saved search won't update the alert. Since we don't have that link anymore later when editing, I wonder if we want to incorporate that in the design of the alert flyout, to make sure users understand that behavior when creating the alert.