Resolves https://github.com/elastic/kibana/issues/162264
## Summary
Adds a limit on the maximum number of actions that can be queued with a
circuit breaker. The limit in serverless is set to 10,000, and 1,000,000
in the other environments.
- If a rule execution exceeds the limit, the circuit breaker kicks in
and stops triggering actions.
- Alerting rule's status updated to warning when circuit breaker is hit
Did not update the `enqueueExecution` bc it's going to be removed in
https://github.com/elastic/kibana/pull/165120.
### Checklist
Delete any items that are not applicable to this PR.
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [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
### To Verify
- Create a 2 rules that have actions
- Set `xpack.actions.queued.max` in kibana.yml to a low number like 2 or
3
- Use the run soon button to queue up actions and hit the circuit
breaker.
- The actions will not be scheduled and the rule status will be set to
warning
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves: https://github.com/elastic/kibana/issues/162262
This PR is the backend changes to add a circuit breaker
`xpack.alerting.rules.maxScheduledPerMinute` to both serverless and
other environments that limits the number of rules to 400 runs / minute
and 10000 runs / minute, respectively. There will be another PR to
follow this one that gives the user UI hints when creating/editing rules
that go over this limit.
This circuit breaker check is applied to the following routes:
- Create Rule
- Update Rule
- Enable Rule
- Bulk Enable Rule
- Bulk Edit Rule
Also adds a new route: `/internal/alerting/rules/_schedule_frequency` to
get the current total schedules per minute (of enabled rules) and the
remaining interval allotment.
### 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: lcawl <lcawley@elastic.co>
Co-authored-by: Xavier Mouligneau <xavier.mouligneau@elastic.co>
In this PR, I'm adding a warning message to the docs for the
`xpack.alerting.rules.run.alerts.max` setting that indicates the
consequences when setting a value higher than the default, while also
indicating it's not supported.
<img width="862" alt="Screenshot 2023-08-21 at 5 03 52 PM"
src="46a7f5d6-f6d5-475a-ab93-edf256eb9141">
cc @lcawl
---------
Co-authored-by: Lisa Cawley <lcawley@elastic.co>
### Summary
This PR adds missing APM/Observability settings to the documentation:
- `observability:apmAgentExplorerView`
- `observability:apmAWSLambdaPriceFactor`
- `observability:apmAWSLambdaRequestCostPerMillion`
- `observability:apmEnableContinuousRollups`
- `observability:apmEnableServiceMetrics`
- `observability:apmLabsButton`
- `observability:apmServiceGroupMaxNumberOfServices`
- `observability:apmDefaultServiceEnvironment`
This PR also adds @elastic/obs-docs as a codeowner to
`/x-pack/plugins/observability/server/ui_settings.ts` so that we don't
miss documenting settings moving forward.
Closes https://github.com/elastic/kibana/issues/118795.
Resolves https://github.com/elastic/kibana/issues/151457.
In this PR, I'm deprecating ephemeral tasks and their related settings.
The following settings have been deprecated with proper warning
messages:
- `xpack.task_manager.ephemeral_tasks.enabled`
- `xpack.task_manager.ephemeral_tasks.request_capacity`
- `xpack.alerting.maxEphemeralActionsPerAlert`
## To verify
1. Set the following in your `kibana.yml`
```
xpack.task_manager.ephemeral_tasks.enabled: true
xpack.task_manager.ephemeral_tasks.request_capacity: 10
xpack.alerting.maxEphemeralActionsPerAlert: 10
```
2. Start up Kibana
3. Notice the deprecation warnings about these settings appear in the
logs
4. Remove settings from step 1
## Sample warning logs
```
[2023-04-18T09:45:36.731-04:00][WARN ][config.deprecation] Configuring "xpack.alerting.maxEphemeralActionsPerAlert" is deprecated and will be removed in a future version. Remove this setting to increase action execution resiliency.
[2023-04-18T09:45:36.732-04:00][WARN ][config.deprecation] Configuring "xpack.task_manager.ephemeral_tasks.enabled" is deprecated and will be removed in a future version. Remove this setting to increase task execution resiliency.
[2023-04-18T09:45:36.732-04:00][WARN ][config.deprecation] Configuring "xpack.task_manager.ephemeral_tasks.request_capacity" is deprecated and will be removed in a future version. Remove this setting to increase task execution resiliency.
```
### Release notes
The following settings have been deprecated. Remove them to increase
task execution resiliency.
- `xpack.task_manager.ephemeral_tasks.enabled`
- `xpack.task_manager.ephemeral_tasks.request_capacity`
- `xpack.alerting.maxEphemeralActionsPerAlert`
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: lcawl <lcawley@elastic.co>
resolves https://github.com/elastic/kibana/issues/135402
Allows deployments to not have the default footer added to alerting
emails via the new `xpack.actions.enableFooterInEmail` config setting.
The default value is `true`, which renders the footer. Setting the
value to `false` will cause no footer to be rendered.
Also changes the footer separator from `--` to `---`, which renders
nicer in HTML, as a `<hr>` element.
This PR adds the new configuration settings to the docs. The
configurations were added in this PR:
https://github.com/elastic/kibana/pull/154013
---------
Co-authored-by: lcawl <lcawley@elastic.co>
## Summary
Add a new action type for Torq which triggers Torq workflows.
This is a re-do of https://github.com/elastic/kibana/pull/139635 ...
### Checklist
Delete any items that are not applicable to this PR.
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: orihoogi <ohoogi@gmail.com>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
