Description
We're implementing a new field in the rule creation/editing and rule details UI for max_signals (The max amount of alerts that will be written per run). This field is restricted to a lower limit of 1 and gives a warning above the upper limit of whatever the alerting config setting xpack.alerting.rules.run.alerts.max is set to (defaults to 1000). The max_signals value defaults to 100 unless xpack.alerting.rules.run.alerts.max is below 100, then it defaults to that value. This addition doesn't affect any of the existing API schemas as max_signals is already a defaultable field, we're just now exposing it to the UI.
Importantly, in the rule executors themselves, we will use the rule's max_signals value UNLESS it is more than xpack.alerting.rules.run.alerts.max in which case we will use that value and log a warning in the detection engine that the max_signals value has been effectively overridden by the baseline config limit
Background & resources
Which documentation set does this change impact?
ESS and serverless
ESS release
8.15
Serverless release
Tues May 14, 2024
Feature differences
The feature is identical in ESS and serverless
API docs impact
No APIs have been changed other than now enforcing certain validations that would have broken rules in the past. Now we return 400 errors when a rule is created/edited with a max_signals value less than 1.
Prerequisites, privileges, feature flags
No response
### Pull Requests
- [x] Serverless docs — https://github.com/elastic/staging-serverless-security-docs/pull/328
- [x] Classic docs — https://github.com/elastic/security-docs/pull/5106
- [x] No need for an API docs (classic) PR
Description
We're implementing a new field in the rule creation/editing and rule details UI for
max_signals(The max amount of alerts that will be written per run). This field is restricted to a lower limit of 1 and gives a warning above the upper limit of whatever the alerting config settingxpack.alerting.rules.run.alerts.maxis set to (defaults to 1000). Themax_signalsvalue defaults to 100 unlessxpack.alerting.rules.run.alerts.maxis below 100, then it defaults to that value. This addition doesn't affect any of the existing API schemas asmax_signalsis already a defaultable field, we're just now exposing it to the UI.Importantly, in the rule executors themselves, we will use the rule's
max_signalsvalue UNLESS it is more thanxpack.alerting.rules.run.alerts.maxin which case we will use that value and log a warning in the detection engine that themax_signalsvalue has been effectively overridden by the baseline config limitBackground & resources
max_signalsvalidation follow up fixes kibana#182643xpack.alerting.rules.run.alerts.max: https://www.elastic.co/guide/en/kibana/current/alert-action-settings-kb.html#alert-settingsWhich documentation set does this change impact?
ESS and serverless
ESS release
8.15
Serverless release
Tues May 14, 2024
Feature differences
The feature is identical in ESS and serverless
API docs impact
No APIs have been changed other than now enforcing certain validations that would have broken rules in the past. Now we return
400errors when a rule is created/edited with amax_signalsvalue less than 1.Prerequisites, privileges, feature flags
No response