-
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
Auto case creation when alerts are detected #153837
Comments
Pinging @elastic/response-ops (Team:ResponseOps) |
Pinging @elastic/response-ops-cases (Feature:Cases) |
thanks @shanisagiv1 A few questions, please:
|
Thanks for the questions @MikePaquette
cc @cnasikas |
Thank you @shanisagiv1. I have a few questions:
About
I suggest using "rule" instead of "Alerting rule" to be consistent with the rest of the UI. |
|
## Summary Depends on: #166267, #170326, #169484, #173740, #173763, #178068, #178307, #178600, #180437 PRs: - #168370 - #169229 - #171754 - #172709 - #173012 - #175107 - #175452 - #175505 - #177033 - #178277 - #177139 - #179796 Fixes: #153837 ## Testing Run Kibana with `--run-examples` if you want to use the "Always firing" rule. Create a rule with a case action in observability and the stack. The security solution is not supported. You should not be able to assign a case action in a security solution rule. 1. Test the "Reopen closed cases" configuration. 2. Test the "Grouping by" configuration. Only one field is allowed. Not all fields are persisted in alerts. If you select a field not part of the alert the case action will create a case where the grouping value is set to `unknow`. 3. Test the "Time window" feature. You can comment out the validation to test for shorter times. 4. Verify that the case action is experimental. 5. Verify that based on the rule type the case is created in the correct solution. 6. Verify that you cannot create a rule with the case action on the basic license. 7. Verify that the execution of the case action fails if you do not have permission for cases. Pending work on the system actions framework level to not allow users to create rules with system actions where they do not have permission. 8. Stress test the case action by creating multiple rules. ### Checklist Delete any items that are not applicable to this PR. - [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [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 ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ## Release notes Automatically create cases when an alert is triggered. --------- Co-authored-by: kibanamachine <[email protected]> Co-authored-by: adcoelho <[email protected]> Co-authored-by: Janki Salvi <[email protected]>
Describe the feature:
Allow users to create cases automatically based on alerting rules when alerts are detected.
This feature should help users to reduce manual work that happens today when users create cases and assign alerts manually.
Business Values:
Describe a specific use case for the feature:
integrate with existing grouping/suppressing capabilities:
So whatever is defined by the pre-processing, the alerts that are generated will be assigned to the case based on the case creation grouping field. All the generated alerts by the same rule will be grouped by the defined values (if any) within a defined window and will be assigned to the same case. when a pre-processing is defined, means just a single alert is created so using the same “value” (e.g. host for pre & post processing) we’ll get a single case with a single alert (because the other alerts with the same host were suppressed by the pre-processing).
Desired flow (draft UX below):
ER:
The text was updated successfully, but these errors were encountered: