Add circuit breaker for max number of actions by connector type

[ersin-erdal]

fixes: #126504

Summary

This PR intends to introduce a new kibana.yml config key that can override the actions.max circuit breaker by connector type(s)

To Verify

Create a rule that has more than one actions of the same type (e.g. Server Log).
Add the below config to your kibana.yml and expect only one of your actions to be triggered.
number_of_triggered_actions value in event log should be 1.
And a warning banner on rule details page should be shown.

xpack.alerting.rules.execution:
  actions:
    connectorTypeOverrides:
      - id: '.server-log'
        max: 1

[elasticmachine]

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

[jbudz]

kibana-docker LGTM

[ersin-erdal]

@elasticmachine merge upstream

[ymao1]

@ersin-erdal Thank you for making the changes to the config! Those look great. I left a question about whether we're actually capping by connector type in the createExecutionHandler logic

[ymao1]

I created an Always Firing rule with 20 alerts that has a server log action for active alerts and an action for recovered alerts.

When I set my config to:

xpack.alerting.rules.execution:
  actions:
    max: 28

I see 20 active server log entries and 8 recovered server log entries. This works as expected.

When I set my config to:

xpack.alerting.rules.execution:
  actions:
    max: 28
    connectorTypeOverrides:
      - id: '.server-log'
        max: 5

I would expect to see 5 active server log entries. Instead I see 20 active server log entries and no recovered server log entries.

[ersin-erdal]

I would expect to see 5 active server log entries. Instead I see 20 active server log entries and no recovered server log entries.

Fixed :)

[ersin-erdal]

@elasticmachine merge upstream

[pmuellr]

LGTM, left a nit comment

[pmuellr]

nit: seems like for this and the next hasReached...() method, we could pass the actionsConfigMap() into the constructor, so we wouldn't have to pass it into these methods directly. Haven't seen where it's used, but it could save having to pass the configMap object around with this object ... OTOH, perhaps there is a reason we do this, or we already have it available and the current structure makes it easier to test ...

[ersin-erdal]

it could be moved in to this class but they are completely different objects.
This class is to hold ruleRunMetrics while actionsConfigMap is the config object from kibana.yml...
Maybe later we can do this refactoring, lets discuss :)

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: f0433b7
• Storybooks Preview
• Webpack Bundle Analyzer

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
alerting	325	324	-1

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
alerting	20	19	-1

Unknown metric groups

API count

id	before	after	diff
alerting	334	333	-1

History

• 💚 Build #39511 succeeded 0c2aa07
• 💚 Build #39239 succeeded 005fe0a
• 💔 Build #39231 failed 2970bca
• 💚 Build #39173 succeeded 5715a96
• 💛 Build #39122 was flaky 9b8657f
• 💔 Build #39083 failed 9bfb570

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream