Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Meta] MVP for Alerting on Dashboards #71560

Closed
2 of 23 tasks
lukeelmers opened this issue Jul 13, 2020 · 4 comments
Closed
2 of 23 tasks

[Meta] MVP for Alerting on Dashboards #71560

lukeelmers opened this issue Jul 13, 2020 · 4 comments
Labels
estimate:small Small Estimated Level of Effort Feature:Alerting/RuleTypes Issues related to specific Alerting Rules Types Feature:Alerting Feature:ExpressionLanguage Interpreter expression language (aka canvas pipeline) Feature:Search Querying infrastructure in Kibana impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort Meta Project:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Team:Visualizations Visualization editors, elastic-charts and infrastructure

Comments

@lukeelmers
Copy link
Member

lukeelmers commented Jul 13, 2020

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

Add Alerts to Lens visualizations

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

Alerting in Discover   Visualize - Visualize

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

@lukeelmers lukeelmers added Feature:Search Querying infrastructure in Kibana Meta Feature:Alerting Feature:ExpressionLanguage Interpreter expression language (aka canvas pipeline) Team:Visualizations Visualization editors, elastic-charts and infrastructure Team:AppArch Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Jul 13, 2020
@kmartastic
Copy link
Contributor

@lukeelmers are maps considered core visualizations?

@lukeelmers
Copy link
Member Author

@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
Copy link
Contributor

Thanks @lukeelmers.

cc: @aaronjcaldwell @thomasneirynck @nreese

@bradquarry
Copy link

bradquarry commented Feb 15, 2021

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.

@exalate-issue-sync exalate-issue-sync bot added impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort loe:medium Medium Level of Effort and removed loe:small Small Level of Effort labels Apr 20, 2021
@petrklapka petrklapka added 1 and removed 1 labels May 10, 2021
@gmmorris gmmorris added the Feature:Alerting/RuleTypes Issues related to specific Alerting Rules Types label Jul 1, 2021
@gmmorris gmmorris added the estimate:small Small Estimated Level of Effort label Aug 18, 2021
@gmmorris gmmorris removed the loe:medium Medium Level of Effort label Sep 2, 2021
@exalate-issue-sync exalate-issue-sync bot added the loe:small Small Level of Effort label Jan 5, 2022
@kobelb kobelb added the needs-team Issues missing a team label label Jan 31, 2022
@botelastic botelastic bot removed the needs-team Issues missing a team label label Jan 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
estimate:small Small Estimated Level of Effort Feature:Alerting/RuleTypes Issues related to specific Alerting Rules Types Feature:Alerting Feature:ExpressionLanguage Interpreter expression language (aka canvas pipeline) Feature:Search Querying infrastructure in Kibana impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort Meta Project:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Team:Visualizations Visualization editors, elastic-charts and infrastructure
Projects
None yet
Development

No branches or pull requests

7 participants