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.

Sign up for GitHub

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

Jump to bottom

[Alerts][License] Advanced handling of the execution alerts with the higher order alert type license. #85634

Closed
YulNaumenko opened this issue Dec 10, 2020 · 2 comments
Closed

[Alerts][License] Advanced handling of the execution alerts with the higher order alert type license. #85634

YulNaumenko opened this issue Dec 10, 2020 · 2 comments
Labels
discuss estimate:needs-research Estimated as too large and requires research to break down into workable issues Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework Feature:Alerting insight Issues related to user insight into platform operations and resilience Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@YulNaumenko
Copy link
Contributor

Currently we have the implementation where alert continue running if its alert type license was expired with logging the proper error with the License reason on each execution.
We should consider a more user friendly approached to handle this use case.
The basic approach is to disable all alerts, which alert types requires a higher order license. In addition it could track a reason like disabledReason: 'user' | 'import' | 'license'. Where we can display a user friendly message in the UI and in the future we add import as a value.
@YulNaumenko YulNaumenko added discuss Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Dec 10, 2020
@elasticmachine
Copy link
Contributor

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

This was referenced Dec 10, 2020
Closed
Closed
@mikecote mikecote mentioned this issue Dec 14, 2020
Closed
@gmmorris gmmorris added the Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework 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 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 16, 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
@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
@mikecote
Copy link
Contributor

mikecote commented Jul 21, 2022 •
edited
Loading

Closing as we feel it's best to keep the rules running as much as possible so when the license does get renewed, the rules start running again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
discuss estimate:needs-research Estimated as too large and requires research to break down into workable issues Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework Feature:Alerting insight Issues related to user insight into platform operations and resilience Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@gmmorris @kobelb @mikecote @elasticmachine @YulNaumenko