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.

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

Onboard an O11y rule type to use FAAD #164220

Closed
mikecote opened this issue Aug 17, 2023 · 3 comments · Fixed by #166664
Closed

Onboard an O11y rule type to use FAAD #164220

mikecote opened this issue Aug 17, 2023 · 3 comments · Fixed by #166664
Assignees
Labels
Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@mikecote
Copy link
Contributor

As part of the next steps to have a single architecture read and write alerts-as-data, we should focus on moving O11y rules away from the rule registry completely. Given there are unknowns, it would be best to start with a single O11y rule type and attempt to make it work without using the rule registry. As issues arise, we should look into triaging / solving them as well.

Definition of done:

  • An O11y rule type using the rule registry can continue to work without the rule registry, only the alerting framework
  • Underlying issues solved
  • Tests are passing
@mikecote mikecote added Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Aug 17, 2023
@elasticmachine
Copy link
Contributor

Pinging @elastic/response-ops (Team:ResponseOps)

@mikecote
Copy link
Contributor Author

I'm adding this one to the current iteration, it is a large issue that that involves R&D to uncover the challenges we will face to move a rule type.

@doakalexi doakalexi assigned doakalexi and unassigned doakalexi Sep 6, 2023
@mikecote mikecote moved this from Todo to Blocked / On hold in AppEx: ResponseOps - Execution & Connectors Sep 8, 2023
@mikecote
Copy link
Contributor Author

I spoke with @simianhacker and we'll use the Metric Threshold rule as the first rule type to onboard to FAAD.

@ymao1 I've unblocked this issue.

@mikecote mikecote moved this from Blocked / On hold to Todo in AppEx: ResponseOps - Execution & Connectors Sep 18, 2023
@ymao1 ymao1 moved this from Todo to In Progress in AppEx: ResponseOps - Execution & Connectors Sep 20, 2023
@ymao1 ymao1 moved this from In Progress to Todo in AppEx: ResponseOps - Execution & Connectors Sep 27, 2023
@ymao1 ymao1 moved this from Todo to In Progress in AppEx: ResponseOps - Execution & Connectors Oct 2, 2023
@ymao1 ymao1 moved this from In Progress to In Review in AppEx: ResponseOps - Execution & Connectors Oct 5, 2023
ymao1 added a commit that referenced this issue Oct 18, 2023
…erts as data (#166664)

Resolves #164220

## Summary

Removes the lifecycle executor wrapper around the metric threshold rule
type executor so that this rule type is using the framework alerts
client to write alerts as data documents.

### Response ops changes
- Passing in task `startedAt` date to the alerts client. Lifecycle
executor rules use this standardized timestamp for the `@timestamp`
field of the AaD doc, as well as for the start and end time of an alert

### Metric threshold rule changes
- Switch to using the alerts client in the executor to report alerts and
to get recovered alert information.

---------

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

4 participants