-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[ResponseOps] Flapping recovered alerts do not show up as active in the alerts table #183735
Labels
bug
Fixes for quality problems that affect the customer experience
Team:ResponseOps
Label for the ResponseOps team (formerly the Cases and Alerting teams)
Comments
doakalexi
added
bug
Fixes for quality problems that affect the customer experience
Team:ResponseOps
Label for the ResponseOps team (formerly the Cases and Alerting teams)
labels
May 17, 2024
github-project-automation
bot
moved this to Awaiting Triage
in AppEx: ResponseOps - Execution & Connectors
May 17, 2024
Pinging @elastic/response-ops (Team:ResponseOps) |
1 task
doakalexi
added a commit
that referenced
this issue
Jun 3, 2024
…he alerts table (#184255) Resolves #183735 ## Summary This bug is caused by event log docs not being written for "pending recovered" alerts on rules with "notify on every run" and "throttle" or notify when set to null. In this PR I remove the logic causing this in `xpack/plugins/alerting/server/lib/get_alerts_for_notification.ts` so now these alerts will be logged in the event log and show up in the ui. ### Checklist - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### To verify - Create an ES Query rule without actions, or with `notifyWhen` set to "notify on every run" or "throttle". Get it to start flapping. - Let the flapping alert start to recover and verify it's still reported as active in the UI until it's been recovered for X executions (the default is 4 if you don't mess with your flapping settings). Ex. of what to expect <img width="1461" alt="Screen Shot 2024-05-29 at 10 53 57 AM" src="https://github.com/elastic/kibana/assets/109488926/144dc22b-a1c7-460f-b430-a6d49771c9bd">
rohanxz
pushed a commit
to honeyn303/kibana
that referenced
this issue
Jun 4, 2024
…he alerts table (elastic#184255) Resolves elastic#183735 ## Summary This bug is caused by event log docs not being written for "pending recovered" alerts on rules with "notify on every run" and "throttle" or notify when set to null. In this PR I remove the logic causing this in `xpack/plugins/alerting/server/lib/get_alerts_for_notification.ts` so now these alerts will be logged in the event log and show up in the ui. ### Checklist - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### To verify - Create an ES Query rule without actions, or with `notifyWhen` set to "notify on every run" or "throttle". Get it to start flapping. - Let the flapping alert start to recover and verify it's still reported as active in the UI until it's been recovered for X executions (the default is 4 if you don't mess with your flapping settings). Ex. of what to expect <img width="1461" alt="Screen Shot 2024-05-29 at 10 53 57 AM" src="https://github.com/elastic/kibana/assets/109488926/144dc22b-a1c7-460f-b430-a6d49771c9bd">
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug
Fixes for quality problems that affect the customer experience
Team:ResponseOps
Label for the ResponseOps team (formerly the Cases and Alerting teams)
When the alert is pending recovered it should be reported as active to the user. Currently it doesn't show up as active or recovered.
The text was updated successfully, but these errors were encountered: