[Response Ops][Alerting] Deprecate alertFactory in favor of AlertsClient
#156445
Assignees
Labels
Feature:Alerting/Alerts-as-Data
Issues related to Alerts-as-data and RuleRegistry
Feature:Alerting
Team:ResponseOps
Label for the ResponseOps team (formerly the Cases and Alerting teams)
Comments
ymao1
added
Feature:Alerting
Team:ResponseOps
|
Pinging @elastic/response-ops (Team:ResponseOps) |
github-project-automation
bot
moved this to Awaiting Triage
in AppEx: ResponseOps - Execution & Connectors
ymao1
moved this from Awaiting Triage
to Todo
in AppEx: ResponseOps - Execution & Connectors
1 task
ymao1
added a commit
that referenced
this issue
Jun 7, 2023
…yload (#158404) Resolves #156443, #156445 ## Summary - Updates `AlertsClient` with `create` API that allows rule executors to report alerts with AAD payload, along with the values for `actionGroup`, `context` and `state`. This proxies the `LegacyAlertsClient` to create alerts via the alerts factory but also saves the reported payload - When the alert doc is bulk written at the end of rule execution, the AAD payload (if specified) is included in the alert document - Deprecates the alert factory that is passed into the rule executors, but this PR does not remove or replace usages of the alert factory - Expose `AlertsClient` services to the rule executors. Note that this PR does not migrate any rule type to use this service. This PR does not opt any rule types into writing the AAD payload or using the AlertsClient API but updates the AAD functional test to do so. To test it out with the ES query rule type, use the following commit: 1b1e139 ## Followup issues - This PR does not add a recovery API to the FAAD AlertsClient so alerts reported via the new alerts client currently do not have a way of specifying recovered payload. ## To Verify - Verify that rule registry rule types still work as expected - Verify that non rule-registry rule types still work as expected - Check out [this commit](1b1e139) which onboards the ES query rule type onto FAAD. Create an ES query rule that alerts and then recovers and verify that the alert documents look as expected. Alternatively, you can modify your own rule type to register with FAAD and write alerts and verify that the alert documents look as expected. ### Checklist - [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
|
Closed with #158404 |
github-project-automation
bot
moved this from In Review
to Done
in AppEx: ResponseOps - Execution & Connectors
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Part 3 of Phase 2 of FAAD:
This issue covers deprecating the
alertFactoryservice passed to rule executors and exposing theAlertsClientservice to rule executors.The text was updated successfully, but these errors were encountered: