[Meta] MVP for Alerting on Dashboards

[lukeelmers]

Summary

With the introduction of the alerting service, we want to introduce support for configuring alerts based on a specific items in a Dashboard.

It's important to understand that since a Dashboard can have various types of panels embedded, there is no "one size fits all" solution for allowing alerts on anything that could potentially be living on a dashboard. Rather, the alerts need to work on a visualization-by-visualization basis, as each type of visualization[0] will have its own shape of data that it is working with.

This poses an interesting challenge: How can we enable alerts on as many types of dashboard visualizations as possible without doing one-off alerting integrations for every single one of them?

Scope

The alerting, app, & arch teams have collaborated on an architecture which would allow alerts to work with minimal configuration for any types of visualizations which are backed by Kibana expressions:

1. Visualize & all core visualizations (including TSVB, Vega, & Timelion)
2. Lens
3. Canvas

This approach would allow for a unified implementation for integrating alerts across all of these apps, with relatively little work that needs to be done on each individual visualization. This meta issue exists to track implementation of alerting across these three apps, so that alerts on these items can be created from a dashboard.

Visualizations which do not leverage expressions, such as the Maps app, will not be able to use this shared infrastructure. Apps falling under this umbrella will need to do their own integration directly with the alerting service in order to provide alerts on their panels from the dashboard.

Tasks

Prerequisites

• [arch] Make inspector data adapters available on the server
  • Create alerting adapter with a unified interface for all vis types to use
• [arch] Support expressions running on the server
  • Make all browser functions available on the server, including services they depend on
  • Support sending inspector adapter data from server expressions
• [alerting] Expose inspector adapters & expressions services to alert executors[1]
• [app + arch] Develop base alert executor which talks to the expressions service & inspector data adapters
• [app] Design & build shared alert creation UI which is used to create the alert executor
• [app] Create shared UI Action for opening the alert creation UI with pre-populated values, which can be triggered by any vis type

Add Alerts to Lens visualizations

• [app] Update Lens vis types to integrate with alerting:
  • lens_data_table
  • lens_metric_chart
  • lens_pie
  • lens_xy_chart

Add Alerts to other visualizations

• [app] Update Visualize vis types to integrate with alerting:
  • vis_type_markdown
  • vis_type_metric
  • vis_type_table
  • vis_type_tagcloug
  • vis_type_timelion
  • vis_type_timeseries
  • vis_type_vega
  • vis_type_vislib

Canvas implementation of Alerting: business priority TBD. Technically, to do this we will need to update Canvas elements to integrate with alerting.

Architecture

Description

Each visualization type registers its "alertable" data to a shared data adapter in a common format (format still TBD). This happens inside of the expression renderer which is specific to that vis. Each vis triggers a UI Action which can tell the alerting config panel to open.

The alerting config panel is used to create the actual alert executor. This executor takes the expression which was used to generate the visualization, and runs it with the expressions service on the server. The executor then "picks up" the data which were registered to the data adapter as a side effect of running the expression, and uses that data to determine whether the alert should be triggered. In this way, the data backing a visualization can be extracted from a vis on the server, without actually rendering the visualization itself.

Work that needs to happen per-visualization

There are a few different shared services that each visualization needs to talk to:

1. UI Actions. To open the alerting configuration panel when a user interacts with a vis, each vis will need to trigger a UI Action so that the panel can be populated with the relevant values.
2. Inspector[2] Data Adapters. In order for the alert executor to know what data to alert on after running the expression, each vis will need to register the data it receives with an Inspector adapter. This will need to be in a unified format which is still TBD.
3. Expressions. Each visualization should already be registering its own renderer with the expressions service, but it will need to make this renderer available on the server as well. The renderer on the server will talk to the data adapter instead of rendering an actual visualization.

Notes

[0] For the purposes of this issue, "visualization" will refer to any Lens visualization, Canvas element, or core vis type created in the Visualize app.
[1] Technically first-class support for expressions-based alerts is not required to accomplish the MVP described here. Rather, the alert executors would only need to have the expressions & data adapter services made available to them.
[2] These are called "inspector" adapters because they are the same framework used by inspector panels when displaying information such as the request/response info for a visualization, or the raw tabular data which was received.

Related meta issue for alerting in Discover: #71099

---

cc @AlonaNadler @shaunmcgough @arisonl @rayafratkina @stacey-gammon @elastic/kibana-alerting-services @elastic/kibana-app @elastic/kibana-app-arch

[kmartastic]

@lukeelmers are maps considered core visualizations?

[lukeelmers]

@kmartastic Not the maps app, no -- this solution only works for visualizations which are built on expressions.

However this approach should still work for the legacy maps visualization types (region map, coordinate maps), as those are using expressions under the hood.

[kmartastic]

Thanks @lukeelmers.

cc: @aaronjcaldwell @thomasneirynck @nreese

[bradquarry]

A team from a big telecom would like to be able to add an alert based on a value within a custom chart in a custom dashboard.