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

[Response Ops][Alerting] Optimize querying for summary alerts in ExecutionHandler #186535

Open
ymao1 opened this issue Jun 20, 2024 · 1 comment
Labels
Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) technical debt Improvement of the software architecture and operational architecture

Comments

@ymao1
Copy link
Contributor

ymao1 commented Jun 20, 2024

More details in #182181

Blocked on #186533 and #186534

Investigate optimizing getting summary queries during action scheduling so that we're not performing duplicate queries and instead caching the query results so they can be reused. If we're getting all the queries up front, we could also look into doing an msearch to perform all the queries at once.

Currently, each action is considered separately from any others and a summary query is performed for each if required. If multiple actions use the same alert filter or don't use any alert filter, we could cache the query results for reuse instead of running the same query repeatedly.

@ymao1 ymao1 added Feature:Alerting technical debt Improvement of the software architecture and operational architecture Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Jun 20, 2024
@elasticmachine
Copy link
Contributor

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

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) technical debt Improvement of the software architecture and operational architecture
Projects
None yet
Development

No branches or pull requests

2 participants