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] Adding ability to run actions for backfill rule runs #200784

Merged
merged 21 commits into from
Jan 20, 2025

Conversation

ymao1
Copy link
Contributor

@ymao1 ymao1 commented Nov 19, 2024

Resolves https://github.com/elastic/response-ops-team/issues/251

Note

This PR includes some saved object schema changes that I will pull out into their own separate PR in order to perform an intermediate release. I wanted to make sure all the schema changes made sense in the overall context of the PR before opening those separate PRs.

Update: PR for intermediate release here: #203184 (Merged)

Summary

Adds ability to run actions for backfill rule runs.

  • Updates schedule backfill API to accept run_actions parameter to specify whether to run actions for backfill.
  • Schedule API accepts any action where frequency.notifyWhen === 'onActiveAlert'. If a rule has multiple actions where some are onActiveAlert and some are onThrottleInterval, the invalid actions will be stripped and a warning returned in the schedule response but valid actions will be scheduled.
  • Connector IDs are extracted and stored as references in the ad hoc run params saved object
  • Any actions that result from a backfill task run are scheduled as low priority tasks

To Verify

  1. Create a detection rule. Make sure you have some past data that the rule can run over in order to generate actions. Make sure you add actions to the rule. For testing, I added some conditional actions so I could see actions running only on backfill runs using kibana.alert.rule.execution.type: "manual". Create actions with and without summaries.
  2. Schedule a backfill either directly via the API or using the detection UI. Verify that actions are run for the backfill runs that generate alerts.

@ymao1 ymao1 force-pushed the backfill-actions branch 8 times, most recently from 07d9365 to 8010638 Compare November 20, 2024 20:40
@kibanamachine
Copy link
Contributor

Flaky Test Runner Stats

🎉 All tests passed! - kibana-flaky-test-suite-runner#7453

[✅] x-pack/test/alerting_api_integration/security_and_spaces/group1/config.ts: 200/200 tests passed.

see run history

@ymao1 ymao1 changed the title Adding ability to run actions for backfill rule runs [Response Ops][Alerting] Adding ability to run actions for backfill rule runs Nov 25, 2024
@@ -171,15 +177,17 @@ export function createBulkExecutionEnqueuerFunction({
executionId: actionToExecute.executionId,
consumer: actionToExecute.consumer,
relatedSavedObjects: relatedSavedObjectWithRefs,
...(actionToExecute.apiKeyId ? { apiKeyId: actionToExecute.apiKeyId } : {}),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Storing apiKeyId in the action_task_param saved object so that the API key invalidation task can query for any scheduled actions that are using invalidated API keys and wait before performing invalidation.

@ymao1 ymao1 self-assigned this Nov 25, 2024
@ymao1 ymao1 added Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v9.0.0 backport:prev-minor Backport to (9.0) the previous minor version (i.e. one version back from main) v8.18.0 release_note:skip Skip the PR/issue when compiling release notes labels Nov 25, 2024
@ymao1 ymao1 marked this pull request as ready for review November 25, 2024 21:19
@ymao1 ymao1 requested review from a team as code owners November 25, 2024 21:19
@elasticmachine
Copy link
Contributor

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

Comment on lines 131 to 133
if (doc['task.priority'].size() != 0) {
return doc['task.priority'].value;
} else if (params.priority_map.containsKey(taskType)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving the conversation from #199218 (comment) here, sorry for the delay!

Either would work! The way it currently is, we would sort by priority=descending which makes more sense in my head but definitely an argument for the reverse

Hmm, is it easy to check what other queueing products like RabbitMQ, Kafka, etc use for priority order? We can see if they do asc or desc and follow suit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For RabbitMQ: Priorities between 1 and 255 are supported, Larger numbers indicate higher priority.

For ActiveMQ: The full range of priority values (0-9) are supported by the [JDBC](https://activemq.apache.org/components/classic/documentation/jdbc-support) message store. For [KahaDB](https://activemq.apache.org/components/classic/documentation/Persistence/kahadb) three priority categories are supported, Low (< 4), Default (= 4) and High (> 4).

For Redis, priority can be implemented using sorted sets, using the score to represent task priority. For sorted sets, If B and A are two elements with a different score, then A > B if A.score is > B.score.

Kafka and SQS do not support event/message level priority. Instead they both recommend adding different topics and reading from them in priority level (read from high priority topic/queue first, then fallback to medium priority if nothing in the high priority topic/queue, etc).

Seems like in general, higher value = higher priority?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for doing the research, it sounds in line with the way we have it implemented today so we are good 👍 ❤️

@ymao1
Copy link
Contributor Author

ymao1 commented Dec 12, 2024

One thing I'm wondering about. To figure out if the action was from a backfill, I used an original_event time value, which seemed to work. I think if I was going to use this, I'd want to have a way to know if this is a backfill, to put some kind of warning in my mustache template like

{{#isBackFill}}**Note: this was generated from a backfill**
{{/isBackFill}}

We can obviously do this later, but I was a little curious and haven't figured out where that would go, in our code ...

We have a field in our alert document: kibana.alert.rule.execution.type which can be either "manual" or "scheduled". Seems like we could do conditional actions to add 2 actions that print different messages based on whether the run was from normal execution or a backfill.

@pmuellr
Copy link
Member

pmuellr commented Dec 12, 2024

We have a field in our alert document: kibana.alert.rule.execution.type which can be either "manual" or "scheduled". Seems like we could do conditional actions to add 2 actions that print different messages based on whether the run was from normal execution or a backfill.

Does "manual" already have a use? Can we use a new value "backfill"?

@ymao1
Copy link
Contributor Author

ymao1 commented Dec 13, 2024

Does "manual" already have a use? Can we use a new value "backfill"?

In this case manual = backfill. The detections UI calls them manual rule runs so they wanted to set the value this way so it shows up consistently in their UI.

@pmuellr
Copy link
Member

pmuellr commented Dec 13, 2024

Seems like we could do conditional actions to add 2 actions that print different messages based on whether the run was from normal execution or a backfill.

Ya, that should work.

I was actually thinking about context variables I guess, and not alert fields. Still think we can just do this later, and we may get some requirements for it as well ...

@ymao1
Copy link
Contributor Author

ymao1 commented Jan 7, 2025

@elasticmachine merge upstream

CAWilson94 pushed a commit to CAWilson94/kibana that referenced this pull request Jan 13, 2025
…iate release (elastic#203184)

## Summary

This PR contains just the schema changes required to support backfill
actions. This is meant for an intermediate release and then the full PR:
elastic#200784 will follow after that.

---------

Co-authored-by: Elastic Machine <[email protected]>
@ymao1
Copy link
Contributor Author

ymao1 commented Jan 16, 2025

@elasticmachine merge upstream

@ymao1 ymao1 added the ci:project-deploy-security Create a Security Serverless Project label Jan 16, 2025
@ymao1
Copy link
Contributor Author

ymao1 commented Jan 17, 2025

@elasticmachine merge upstream

@ymao1
Copy link
Contributor Author

ymao1 commented Jan 17, 2025

@elasticmachine merge upstream

@ymao1
Copy link
Contributor Author

ymao1 commented Jan 20, 2025

@elasticmachine merge upstream

@elasticmachine
Copy link
Contributor

elasticmachine commented Jan 20, 2025

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] FTR Configs #21 / console app console autocomplete feature Autocomplete behavior JSON autocompletion with placeholder fields

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
taskManager 61 62 +1
Unknown metric groups

API count

id before after diff
taskManager 104 105 +1

ESLint disabled line counts

id before after diff
@kbn/test-suites-xpack 737 738 +1

Total ESLint disabled count

id before after diff
@kbn/test-suites-xpack 762 763 +1

History

cc @ymao1

@ymao1 ymao1 merged commit 075806b into elastic:main Jan 20, 2025
8 checks passed
@ymao1 ymao1 deleted the backfill-actions branch January 20, 2025 15:03
@kibanamachine
Copy link
Contributor

Starting backport for target branches: 8.x

https://github.com/elastic/kibana/actions/runs/12870773918

@kibanamachine
Copy link
Contributor

💔 All backports failed

Status Branch Result
8.x Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 200784

Questions ?

Please refer to the Backport tool documentation

@ymao1
Copy link
Contributor Author

ymao1 commented Jan 20, 2025

💚 All backports created successfully

Status Branch Result
8.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

ymao1 added a commit to ymao1/kibana that referenced this pull request Jan 20, 2025
…ule runs (elastic#200784)

Resolves elastic/response-ops-team#251

## Note

This PR includes some saved object schema changes that I will pull out
into their own separate PR in order to perform an intermediate release.
I wanted to make sure all the schema changes made sense in the overall
context of the PR before opening those separate PRs.

Update: PR for intermediate release here:
elastic#203184 (Merged)

## Summary

Adds ability to run actions for backfill rule runs.

- Updates schedule backfill API to accept `run_actions` parameter to
specify whether to run actions for backfill.
- Schedule API accepts any action where `frequency.notifyWhen ===
'onActiveAlert'`. If a rule has multiple actions where some are
`onActiveAlert` and some are `onThrottleInterval`, the invalid actions
will be stripped and a warning returned in the schedule response but
valid actions will be scheduled.
- Connector IDs are extracted and stored as references in the ad hoc run
params saved object
- Any actions that result from a backfill task run are scheduled as low
priority tasks

## To Verify

1. Create a detection rule. Make sure you have some past data that the
rule can run over in order to generate actions. Make sure you add
actions to the rule. For testing, I added some conditional actions so I
could see actions running only on backfill runs using
`kibana.alert.rule.execution.type: "manual"`. Create actions with and
without summaries.
2. Schedule a backfill either directly via the API or using the
detection UI. Verify that actions are run for the backfill runs that
generate alerts.

---------

Co-authored-by: Elastic Machine <[email protected]>
(cherry picked from commit 075806b)

# Conflicts:
#	x-pack/platform/plugins/shared/actions/server/create_execute_function.ts
ymao1 added a commit that referenced this pull request Jan 21, 2025
…fill rule runs (#200784) (#207273)

# Backport

This will backport the following commits from `main` to `8.x`:
- [[Response Ops][Alerting] Adding ability to run actions for backfill
rule runs (#200784)](#200784)

<!--- Backport version: 9.6.4 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)

<!--BACKPORT [{"author":{"name":"Ying
Mao","email":"[email protected]"},"sourceCommit":{"committedDate":"2025-01-20T15:03:33Z","message":"[Response
Ops][Alerting] Adding ability to run actions for backfill rule runs
(#200784)\n\nResolves
https://github.com/elastic/response-ops-team/issues/251\r\n\r\n\r\n##
Note\r\n\r\nThis PR includes some saved object schema changes that I
will pull out\r\ninto their own separate PR in order to perform an
intermediate release.\r\nI wanted to make sure all the schema changes
made sense in the overall\r\ncontext of the PR before opening those
separate PRs.\r\n\r\nUpdate: PR for intermediate release
here:\r\nhttps://github.com//pull/203184
(Merged)\r\n\r\n## Summary\r\n\r\nAdds ability to run actions for
backfill rule runs.\r\n\r\n- Updates schedule backfill API to accept
`run_actions` parameter to\r\nspecify whether to run actions for
backfill.\r\n- Schedule API accepts any action where
`frequency.notifyWhen ===\r\n'onActiveAlert'`. If a rule has multiple
actions where some are\r\n`onActiveAlert` and some are
`onThrottleInterval`, the invalid actions\r\nwill be stripped and a
warning returned in the schedule response but\r\nvalid actions will be
scheduled.\r\n- Connector IDs are extracted and stored as references in
the ad hoc run\r\nparams saved object\r\n- Any actions that result from
a backfill task run are scheduled as low\r\npriority tasks\r\n\r\n## To
Verify\r\n\r\n1. Create a detection rule. Make sure you have some past
data that the\r\nrule can run over in order to generate actions. Make
sure you add\r\nactions to the rule. For testing, I added some
conditional actions so I\r\ncould see actions running only on backfill
runs using\r\n`kibana.alert.rule.execution.type: \"manual\"`. Create
actions with and\r\nwithout summaries.\r\n2. Schedule a backfill either
directly via the API or using the\r\ndetection UI. Verify that actions
are run for the backfill runs that\r\ngenerate
alerts.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<[email protected]>","sha":"075806bffa78cc4f42e61483dcbd24de3c87d3c8","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Alerting","release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","ci:project-deploy-security","v8.18.0"],"title":"[Response
Ops][Alerting] Adding ability to run actions for backfill rule
runs","number":200784,"url":"https://github.com/elastic/kibana/pull/200784","mergeCommit":{"message":"[Response
Ops][Alerting] Adding ability to run actions for backfill rule runs
(#200784)\n\nResolves
https://github.com/elastic/response-ops-team/issues/251\r\n\r\n\r\n##
Note\r\n\r\nThis PR includes some saved object schema changes that I
will pull out\r\ninto their own separate PR in order to perform an
intermediate release.\r\nI wanted to make sure all the schema changes
made sense in the overall\r\ncontext of the PR before opening those
separate PRs.\r\n\r\nUpdate: PR for intermediate release
here:\r\nhttps://github.com//pull/203184
(Merged)\r\n\r\n## Summary\r\n\r\nAdds ability to run actions for
backfill rule runs.\r\n\r\n- Updates schedule backfill API to accept
`run_actions` parameter to\r\nspecify whether to run actions for
backfill.\r\n- Schedule API accepts any action where
`frequency.notifyWhen ===\r\n'onActiveAlert'`. If a rule has multiple
actions where some are\r\n`onActiveAlert` and some are
`onThrottleInterval`, the invalid actions\r\nwill be stripped and a
warning returned in the schedule response but\r\nvalid actions will be
scheduled.\r\n- Connector IDs are extracted and stored as references in
the ad hoc run\r\nparams saved object\r\n- Any actions that result from
a backfill task run are scheduled as low\r\npriority tasks\r\n\r\n## To
Verify\r\n\r\n1. Create a detection rule. Make sure you have some past
data that the\r\nrule can run over in order to generate actions. Make
sure you add\r\nactions to the rule. For testing, I added some
conditional actions so I\r\ncould see actions running only on backfill
runs using\r\n`kibana.alert.rule.execution.type: \"manual\"`. Create
actions with and\r\nwithout summaries.\r\n2. Schedule a backfill either
directly via the API or using the\r\ndetection UI. Verify that actions
are run for the backfill runs that\r\ngenerate
alerts.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<[email protected]>","sha":"075806bffa78cc4f42e61483dcbd24de3c87d3c8"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/200784","number":200784,"mergeCommit":{"message":"[Response
Ops][Alerting] Adding ability to run actions for backfill rule runs
(#200784)\n\nResolves
https://github.com/elastic/response-ops-team/issues/251\r\n\r\n\r\n##
Note\r\n\r\nThis PR includes some saved object schema changes that I
will pull out\r\ninto their own separate PR in order to perform an
intermediate release.\r\nI wanted to make sure all the schema changes
made sense in the overall\r\ncontext of the PR before opening those
separate PRs.\r\n\r\nUpdate: PR for intermediate release
here:\r\nhttps://github.com//pull/203184
(Merged)\r\n\r\n## Summary\r\n\r\nAdds ability to run actions for
backfill rule runs.\r\n\r\n- Updates schedule backfill API to accept
`run_actions` parameter to\r\nspecify whether to run actions for
backfill.\r\n- Schedule API accepts any action where
`frequency.notifyWhen ===\r\n'onActiveAlert'`. If a rule has multiple
actions where some are\r\n`onActiveAlert` and some are
`onThrottleInterval`, the invalid actions\r\nwill be stripped and a
warning returned in the schedule response but\r\nvalid actions will be
scheduled.\r\n- Connector IDs are extracted and stored as references in
the ad hoc run\r\nparams saved object\r\n- Any actions that result from
a backfill task run are scheduled as low\r\npriority tasks\r\n\r\n## To
Verify\r\n\r\n1. Create a detection rule. Make sure you have some past
data that the\r\nrule can run over in order to generate actions. Make
sure you add\r\nactions to the rule. For testing, I added some
conditional actions so I\r\ncould see actions running only on backfill
runs using\r\n`kibana.alert.rule.execution.type: \"manual\"`. Create
actions with and\r\nwithout summaries.\r\n2. Schedule a backfill either
directly via the API or using the\r\ndetection UI. Verify that actions
are run for the backfill runs that\r\ngenerate
alerts.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<[email protected]>","sha":"075806bffa78cc4f42e61483dcbd24de3c87d3c8"}},{"branch":"8.x","label":"v8.18.0","branchLabelMappingKey":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

---------

Co-authored-by: kibanamachine <[email protected]>
cqliu1 pushed a commit to cqliu1/kibana that referenced this pull request Jan 21, 2025
…ule runs (elastic#200784)

Resolves elastic/response-ops-team#251


## Note

This PR includes some saved object schema changes that I will pull out
into their own separate PR in order to perform an intermediate release.
I wanted to make sure all the schema changes made sense in the overall
context of the PR before opening those separate PRs.

Update: PR for intermediate release here:
elastic#203184 (Merged)

## Summary

Adds ability to run actions for backfill rule runs.

- Updates schedule backfill API to accept `run_actions` parameter to
specify whether to run actions for backfill.
- Schedule API accepts any action where `frequency.notifyWhen ===
'onActiveAlert'`. If a rule has multiple actions where some are
`onActiveAlert` and some are `onThrottleInterval`, the invalid actions
will be stripped and a warning returned in the schedule response but
valid actions will be scheduled.
- Connector IDs are extracted and stored as references in the ad hoc run
params saved object
- Any actions that result from a backfill task run are scheduled as low
priority tasks

## To Verify

1. Create a detection rule. Make sure you have some past data that the
rule can run over in order to generate actions. Make sure you add
actions to the rule. For testing, I added some conditional actions so I
could see actions running only on backfill runs using
`kibana.alert.rule.execution.type: "manual"`. Create actions with and
without summaries.
2. Schedule a backfill either directly via the API or using the
detection UI. Verify that actions are run for the backfill runs that
generate alerts.

---------

Co-authored-by: Elastic Machine <[email protected]>
viduni94 pushed a commit to viduni94/kibana that referenced this pull request Jan 23, 2025
…ule runs (elastic#200784)

Resolves elastic/response-ops-team#251


## Note

This PR includes some saved object schema changes that I will pull out
into their own separate PR in order to perform an intermediate release.
I wanted to make sure all the schema changes made sense in the overall
context of the PR before opening those separate PRs.

Update: PR for intermediate release here:
elastic#203184 (Merged)

## Summary

Adds ability to run actions for backfill rule runs.

- Updates schedule backfill API to accept `run_actions` parameter to
specify whether to run actions for backfill.
- Schedule API accepts any action where `frequency.notifyWhen ===
'onActiveAlert'`. If a rule has multiple actions where some are
`onActiveAlert` and some are `onThrottleInterval`, the invalid actions
will be stripped and a warning returned in the schedule response but
valid actions will be scheduled.
- Connector IDs are extracted and stored as references in the ad hoc run
params saved object
- Any actions that result from a backfill task run are scheduled as low
priority tasks

## To Verify

1. Create a detection rule. Make sure you have some past data that the
rule can run over in order to generate actions. Make sure you add
actions to the rule. For testing, I added some conditional actions so I
could see actions running only on backfill runs using
`kibana.alert.rule.execution.type: "manual"`. Create actions with and
without summaries.
2. Schedule a backfill either directly via the API or using the
detection UI. Verify that actions are run for the backfill runs that
generate alerts.

---------

Co-authored-by: Elastic Machine <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:prev-minor Backport to (9.0) the previous minor version (i.e. one version back from main) ci:project-deploy-security Create a Security Serverless Project Feature:Alerting release_note:skip Skip the PR/issue when compiling release notes Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v8.18.0 v9.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants