[Response Ops][Alerting] Update alerts-as-data ILM policy name to be consistent between framework & rule registry

[ymao1]

Resolves #150331

Summary

In a previous PR we started installing an ILM policy for framework alerts as data when the xpack.alerting.enableFrameworkAlerts config flag is set to true. In that PR we used a different name than what is used by the rule registry even though the policy bodies were the same.

In this PR, we are consolidating the naming of the two ILM policies so that we are only ever installing 1 policy. The xpack.alerting.enableFrameworkAlerts config is used to determine which plugin is responsible for installing the policy. When set to true, the alerting plugin installs the policy. When set the false, the rule registry installs the policy. This is an incremental step toward the alerting framework absorbing all of the resource installation functionality of the rule registry

To Verify

A few things to verify:

1. Verify that the alerting plugin installs the policy when xpack.alerting.enableFrameworkAlerts=true

• Set xpack.alerting.enableFrameworkAlerts: true in your Kibana config
• Start a fresh ES and Kibana instance
• Verify that an ILM policy with name .alerts-ilm-policy is installed
• Create a metric threshold rule that creates an alert
• Verify that there is an index template called .alerts-observability.metrics.alerts-default-index-template that uses the .alerts-ilm-policy policy

2. Verify that the rule registry installs the policy when xpack.alerting.enableFrameworkAlerts=false

• Set xpack.alerting.enableFrameworkAlerts: false in your Kibana config
• Start a fresh ES and Kibana instance
• Verify that an ILM policy with name .alerts-ilm-policy is installed
• Create a metric threshold rule that creates an alert
• Verify that there is an index template called .alerts-observability.metrics.alerts-default-index-template that uses the .alerts-ilm-policy policy

3. Verify that we can switch between configurations

• Set xpack.alerting.enableFrameworkAlerts: false in your Kibana config
• Start a fresh ES and Kibana instance
• Verify that an ILM policy with name .alerts-ilm-policy is installed
• Create a metric threshold rule that creates an alert
• Verify that there is an index template called .alerts-observability.metrics.alerts-default-index-template that uses the .alerts-ilm-policy policy
• Change xpack.alerting.enableFrameworkAlerts: true
• Restart Kibana
• Verify there are no errors, and the rule can still write alerts

[ymao1]

@elasticmachine merge upstream

[ymao1]

@elasticmachine merge upstream

[elasticmachine]

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

[ymao1]

@elasticmachine merge upstream

[ymao1]

@elasticmachine merge upstream

[doakalexi]

Tested locally and works as expected, LGTM!

[mikecote]

Changes LGTM! I tested locally in various scenarios and the policy was managed as expected.

[ymao1]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 1632058

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	466	477	+11

Unknown metric groups

API count

id	before	after	diff
alerting	476	488	+12

History

• 💚 Build #107533 succeeded 29b78f3
• 💚 Build #106842 succeeded 6625332
• 💔 Build #106629 failed 85ab478
• 💚 Build #106183 succeeded 900d5ff
• 💚 Build #105881 succeeded 41ddf43
• 💔 Build #105794 failed d21538d

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

cc @ymao1