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

[alerts] provide an "explain" capability to show elasticsearch queries that alerts will run #84417

Open
pmuellr opened this issue Nov 26, 2020 · 1 comment
Assignees
Labels
estimate:needs-research Estimated as too large and requires research to break down into workable issues Feature:Alerting/RulesManagement Issues related to the Rules Management UX Feature:Alerting impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. insight Issues related to user insight into platform operations and resilience resilience Issues related to Platform resilience in terms of scale, performance & backwards compatibility Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@pmuellr
Copy link
Member

pmuellr commented Nov 26, 2020

Alerts are commonly implemented using elasticsearch queries built from the alert parameters provided by customers. While you can pretty much guess how those queries are built, it would be nice to provide some UX where a customer can show the exact query that will be used. Kind of like an "explain" for alerts.

This came up in the context of an SDH where a customer wanted to compare an elasticsearch query they wanted to use in an alert, to the alert parameters they thought would match. There's no way to do that comparison today, without looking at the code, and even that won't be easy since the query builders can get complex.

Example: provide a link in the alert parameter forms, which when clicked, will display a popup with the query used, filled in with parameters in the form.

Some notes/complications:

  • alerts don't HAVE to be elasticsearch queries - my first thought was to expect alertTypes to return a JSON-able object which the UI would render nicely, but that won't work if your query was KQL/lucene syntax
  • alerts could be making > 1 queries per alertType executor invocation, so we should allow for showing multiple queries, and no queries!
  • how would we represent values used in the query that don't come from the params, but from the alert state or other dynamic sources that we won't have available; and if the alert type is doing multiple queries, the queries other than the first might use results from previous queries.
  • this will be some new API that alertTypes will have to implement, probably make it optional to allow alertTypes to "opt-in" to this
  • we'll need an HTTP endpoint the UI code can call to get the representation, and so should be in the alertsClient as well
  • it would be nice to actually allow that query to be executed and show the results; maybe we don't need to go that far - if the query could run in the Dev Tools Console, we could allow a "clipboard paste" button, and navigation to the console, to allow it to be pasted in there and run ad hoc.
@pmuellr pmuellr added Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Nov 26, 2020
@elasticmachine
Copy link
Contributor

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

@gmmorris gmmorris added the Feature:Alerting/RulesManagement Issues related to the Rules Management UX label Jul 1, 2021
@gmmorris gmmorris added the loe:needs-research This issue requires some research before it can be worked on or estimated label Jul 14, 2021
@gmmorris gmmorris added resilience Issues related to Platform resilience in terms of scale, performance & backwards compatibility insight Issues related to user insight into platform operations and resilience estimate:needs-research Estimated as too large and requires research to break down into workable issues labels Aug 13, 2021
@gmmorris gmmorris removed the loe:needs-research This issue requires some research before it can be worked on or estimated label Sep 2, 2021
@gmmorris gmmorris added the impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. label Sep 16, 2021
@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
@XavierM XavierM self-assigned this Mar 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
estimate:needs-research Estimated as too large and requires research to break down into workable issues Feature:Alerting/RulesManagement Issues related to the Rules Management UX Feature:Alerting impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. insight Issues related to user insight into platform operations and resilience resilience Issues related to Platform resilience in terms of scale, performance & backwards compatibility Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
No open projects
Development

No branches or pull requests

5 participants