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

Ability to persist alert instance state without firing #47713

Closed
mikecote opened this issue Oct 9, 2019 · 4 comments
Closed

Ability to persist alert instance state without firing #47713

mikecote opened this issue Oct 9, 2019 · 4 comments
Labels
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 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

@mikecote
Copy link
Contributor

mikecote commented Oct 9, 2019

Have a non-hacked way to persist alert instance state. Maybe by default? and have something different for cleanup of old alert instances.
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-stack-services (Team:Stack Services)

@bmcconaghy bmcconaghy added Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) and removed Team:Stack Services labels Dec 12, 2019
@chrisronline
Copy link
Contributor

++

I'd be nice to have access to historical alert instance data. In Stack Monitoring, nearly every single page is governed by a time picker and it'd be great for users to be able to go back in history and view alerts that were firing at that time. It'd also help us build out some kind of historical log of Stack Monitoring alerts.

@chrisronline chrisronline mentioned this issue Apr 10, 2020
Closed
@mikecote
Copy link
Contributor Author

To add more context: This relates to creating alert instances in the alert executor, setting the state but not calling scheduleActions. What happens now is the alert instance state won't update in task manager and actually clean up the alert instance (recovered).

@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 resilience Issues related to Platform resilience in terms of scale, performance & backwards compatibility 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
@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 Author

Closing due to lack of activty.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
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 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
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@chrisronline @gmmorris @kobelb @bmcconaghy @mikecote @elasticmachine