[Response Ops][Alerting] Install resources needed for framework alerts-as-data #145581

ymao1 · 2022-11-17T15:27:29Z

Summary

Adds alerting config for enableFrameworkAlerts
When xpack.alerting.enableFrameworkAlerts=true, AlertsService is initialized during the alerting plugin setup phase
Adds optional alerts definition to the RuleType definition which allows a rule type to specify a context and a field mapping for that context
AlertsService.initialize()
- installs an ILM policy that will be used by all alerts-as-data indices - alerts-default-ilm-policy
- installs a component template that will be used by all alerts-as-data indices - alerts-common-component-template, including all the mappings for fields needed by the framework
Rule type registration - when a rule type with an alerts definition is registered, the context and field map are registered with the AlertService. When AlertsService initialization is completed successfully, context specific resources are installed.
Context specific resources:
- installs context specific component template that reflects the registered field map - alerts-${context}-component-template
- installs context specific index template for the default namespace - .alerts-${context}-default-template
- creates context specific concrete write index for the default namespace - .alerts-${context}-default-000001
Resource installation retries for transient ES errors and short-circuits when a timeout value is reached

Notes

We explore the possibility of creating a single index template per context and re-using it for space-aware concrete indices but a rollover alias (which must be space-aware) must be attached to an index template so it is not feasible to only have a single index template
There will be a followup issue for create space-specific index templates/indices as needed to support detection rules desire to separate alerts by space.

To Verify

set xpack.alerting.enableFrameworkAlerts: true in your kibana.yml
modify x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type.ts to define a custom field mapping for the stack context

--- a/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type.ts
+++ b/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type.ts
@@ -187,5 +187,14 @@ export function getRuleType(
     },
     producer: STACK_ALERTS_FEATURE_ID,
     doesSetRecoveryContext: true,
+    alerts: {
+      context: 'stack',
+      fieldMap: {
+        'kibana.alert.threshold': {
+          required: false,
+          type: 'long',
+        },
+      },
+    },
   };
 }

start up ES and Kibana and verify that the correct resources are installed. The following should be created:
- ILM policy - alerts-default-ilm-policy
- Common component template - alerts-common-component-template
- Stack component template - alerts-stack-component-template
- Stack index template for default space - .alerts-stack-default-template
- Stack write index for default space - .alerts-stack-default-000001
verify that the index template uses both component templates and that the expected mappings are applied to the index
try making non-destructive, additive only changes to the common component template or the stack context field mapping and verify that the concrete index mappings are updated.

Checklist

Unit or functional tests were updated or added to match the most common scenarios

…nt templates

…g/faad-resources

ymao1 · 2022-12-13T18:46:13Z

@elasticmachine merge upstream

…g/faad-resources

…eout

…g/faad-resources

CoenWarmer

AO owned changed LGTM

pmuellr

Structure looks great! Added some nit comments ...

packages/kbn-rule-data-utils/src/default_alerts_as_data.ts

x-pack/plugins/alerting/server/alerts_service/alerts_service.ts

pmuellr · 2023-01-19T22:51:24Z

x-pack/plugins/alerting/server/alerts_service/alerts_service.ts

+    );
+  }
+
+  private async updateTotalFieldLimitSetting(


I'm always a little worried about touching existing indices. Did we have some cases of updating the event log indices that caused problems? Closed indices or something like that? It's tough because if we are kinda "lenient" for some of these errors, they'll just come back and bite us later.

Feels like the code below is probably the best thing now - log an error early exit.

pmuellr · 2023-01-19T22:58:33Z

x-pack/plugins/alerting/server/alerts_service/alerts_service.ts

+    } catch (e) {
+      this.options.logger.error(e);
+
+      if (e?.message.indexOf('Server is stopping') < 0) {


Could we set a flag in the pluginStop$ observer to check if we're shutting down instead? Or make the message a const and use it both to throw the error message AND check it here?

Actually, what happens if we throw the error during shutdown, and just skip the conditional?

pmuellr · 2023-01-19T23:29:50Z

x-pack/plugins/alerting/server/alerts_service/default_lifecycle_policy.ts

+export const DEFAULT_ILM_POLICY = {
+  policy: {
+    _meta: {
+      managed: true,


could add some meta here too, maybe? I guess _meta.managed is defined by the platform, can we add more?

pmuellr · 2023-01-19T23:34:33Z

x-pack/test/alerting_api_integration/common/config.ts

@@ -185,6 +185,7 @@ export function createTestConfig(name: string, options: CreateTestConfigOptions)
          `--xpack.alerting.rules.run.actions.connectorTypeOverrides=${JSON.stringify([
            { id: 'test.capped', max: '1' },
          ])}`,
+          `--xpack.alerting.enableFrameworkAlerts=true`,


Let's remember to ask folks to add this to their kibana.dev.ymlfiles, after the merge, so we'll get some early testing of the initialization bits.

ymao1 · 2023-01-23T13:03:23Z

@elasticmachine merge upstream

ymao1 · 2023-01-24T00:06:02Z

@elasticmachine merge upstream

kibana-ci · 2023-01-24T01:49:59Z

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
`apm`	1364	1365	+1
`cases`	588	589	+1
`infra`	1221	1222	+1
`observability`	495	496	+1
`securitySolution`	3534	3535	+1
`synthetics`	1336	1337	+1
`triggersActionsUi`	495	496	+1
total			+7

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
`@kbn/rule-data-utils`	94	96	+2
`alerting`	456	457	+1
total			+3

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`	38	39	+1

Unknown metric groups

API count

id	before	after	diff
`@kbn/rule-data-utils`	97	99	+2
`alerting`	466	467	+1
total			+3

ESLint disabled line counts

id	before	after	diff
`alerting`	71	77	+6

Total ESLint disabled count

id	before	after	diff
`alerting`	72	78	+6

History

💚 Build #101861 succeeded 19b8818
💔 Build #101805 failed cb680ef2b92985244a6b97a3af93ed251ff36fe2
💔 Build #101774 failed b113946acb9465dc37a8b0e1cc69c0fd32d8c68f
💛 Build #101228 was flaky 3ff7e81
💚 Build #100797 succeeded 4080def
💚 Build #100695 succeeded 9176eec

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

cc @ymao1

…consistent between framework & rule registry (#150334) Resolves #150331 ## Summary In a previous [PR](#145581) 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 --------- Co-authored-by: Kibana Machine <[email protected]>

…for framework alerts as data (#150384) Resolves #150358 ## Summary In a previous [PR](#145581) we started installing a common component template for framework alerts as data when the `xpack.alerting.enableFrameworkAlerts` config flag is set to true. In that PR we used a different naming pattern than what is used by the rule registry for its component templates. In this PR we are doing the following: * Renaming the installed `alerts-common-component-template` to `.alerts-framework-mappings`. * Creating and installing `.alerts-legacy-alert-mappings` component template when `enableFrameworkAlerts: true` on alerting plugin setup * The combination of the two component templates creates the same set of mappings as the rule registry technical component template * Creating and installing `.alerts-ecs-mappings` component template when `enableFrameworkAlerts: true` on alerting plugin setup (when `enableFrameworkAlerts: false`, the rule registry continues to install this component template * Using the `@kbn/ecs` package provided by core to generate the ECS field map. The rule registry will continue to install the existing ECS field map which is actually a subset of ECS fields * Adding `useLegacy` and `useEcs` flags that allow rule types to specify whether to include the legacy alerts component template and the ECS component template when registering with framework alerts-as-data. * Moved some common functions to alerting framework from the rule registry ## Things to note * When generating the ECS field map, we are now including the `ignore_above` setting from the `@kbn/ecs` package. This changes the ECS component template to include those settings. I tested updating an index with just `"type":"keyword"` mappings to add the `ignore_above` field to the mapping and had no issues so this seems like an additive change to the mapping that will hopefully prevent problems in the future. * The rule registry ECS component template also includes the technical fields which is redundant because the technical component template is automatically installed for all index templates so the framework ECS component template only contains ECS fields. | Previous mapping | Updated mapping | | ----------- | ----------- | | `{ "organization": { "type": "keyword" } }` | `{ "organization": { "type": "keyword", "ignore_above": 1024 } }` | ## To Verify ### Verify that the generated component templates are as expected: Get the following **While running `main`:** 1. Get the ECS component template `GET _component_template/.alerts-ecs-mappings` 2. Get the technical component template `GET _component_template/.alerts-technical-mappings` 3. Create a detection rule that creates an alert and then get the index mapping for the concrete security alert index `GET .internal.alerts-security.alerts-default-000001/_mapping` **While running this branch with `xpack.alerting.enableFrameworkAlerts: false`:** 4. Get the ECS component template `GET _component_template/.alerts-ecs-mappings` 5. Get the technical component template `GET _component_template/.alerts-technical-mappings` 6. Create a detection rule that creates an alert and then get the index mapping for the concrete security alert index `GET .internal.alerts-security.alerts-default-000001/_mapping` **While running this branch with `xpack.alerting.enableFrameworkAlerts: true`:** 7. Get the ECS component template `GET _component_template/.alerts-ecs-mappings` 8. Get the technical component template `GET _component_template/.alerts-technical-mappings` 9. Create a detection rule that creates an alert and then get the index mapping for the concrete security alert index `GET .internal.alerts-security.alerts-default-000001/_mapping` 10. Verify that component templates exist for `.alerts-framework-mappings` and `.alerts-legacy-alert-mappings` **Compare the ECS component templates** Compare 1 and 4 (ECS component template from `main` and installed by rule registry in this branch). The difference should be: * no difference in ECS fields * because the rule registry ECS component template also includes technical fields, you will see the 2 new technical fields in this branch Compare 4 and 7 (ECS component template from rule registry & alerting framework in this branch). * some new ECS fields for alerting installed template * each `keyword` mapped field for alerting installed template should have `ignore_above` setting * no `kibana.*` fields in the alerting installed template **Compare the technical component templates** Compare 2 and 5 (technical component template from `main` and installed by rule registry in this branch). The difference should be: * 2 new `kibana.alert` fields (`flapping_history` and `last_detected`) Compare 5 and 8 (technical component template from rule registry & alerting framework in this branch). * there should be no difference! **Compare the index mappings** Compare 3 and 6 (index mapping from `main` and installed by rule registry in this branch). The difference should be: * 2 new `kibana.alert` fields (`flapping_history` and `last_detected`) Compare 6 and 9 (index mapping from rule registry & alerting framework in this branch). * some new ECS fields * each `keyword` mapped ECS field should have `ignore_above` setting ### Verify that the generated component templates work with existing rule registry index templates & indices: 1. Run `main` or a previous version and create a rule that uses both ECS component templates & technical component templates (detection rules use both). Let it run a few times. 2. Using the same ES data, switch to this branch with `xpack.alerting.enableFrameworkAlerts: false` and verify Kibana starts with no rule registry errors and the rule continues to run as expected. 3. Using the same ES data, switch to this branch with `xpack.alerting.enableFrameworkAlerts: true` and verify Kibana starts with no alerting or rule registry errors and the rule continues to run as expected. Verify that the mapping on the existing `.internal.alerts-security.alerts-default-000001` has been updated to include the latest ECS mappings and the two new technical fields. ### Checklist Delete any items that are not applicable to this PR. - [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 <[email protected]> Co-authored-by: Mike Côté <[email protected]>

…ponent templates, index templates and concrete write index to framework for alerts-as-data (#151792) Resolves #151697 ## Summary In a previous [PR](#145581) we started installing a context-specific component templates, index templates and concrete write indices for framework alerts as data when the `xpack.alerting.enableFrameworkAlerts` config flag is set to true. In that PR we used a different naming pattern than what is used by the rule registry for those resources. In this PR, we are aligning the naming of these resources with the rule registry and installing these resources on alerting plugin setup when `enableFrameworkAlerts: true`. If the flag is set to false, the rule registry will continue to handle this resource installation. In this PR we are doing the following: * Registering all rules currently registered with the rule registry with the alerting framework. This registration allows the alerting framework to build context specific component templates. Because this PR only addresses resource installation, rules will continue to be registered with the rule registry. * When `enableFrameworkAlerts: true`: * The framework installs the context specific component template with the following naming convention: `.alerts-{context}.alerts-mappings`. This matches what the rule registry currently installs so the transition should be seamless * The framework installs the context specific index template for the `default` space with the following name: `.alerts-{context}.alerts-default-index-template`. Space awareness will be addressed in a followup PR. This matches the current rule registry naming.This index template will reference (1) ECS component template (if `useEcs: true`), (2) context-specific component template, (3) legacy alert component template and (4) framework component template where the legacy alert component template + framework component template = technical component template (from the rule registry). * The framework creates or updates the concrete write index for the `default` space with the naming convention: `.internal.alerts-{context}.alerts-default-000001`. Space awareness will be addressed in a followup PR. This matches the current rule registry naming. * The installation of the index template & write index differs from the rule registry in that it occurs on alerting plugin start vs the first rule run. * We modified the rule registry resource installer to skip installation of these resources when `enableFrameworkAlerts: true`. In addition, it will wait for the alerting resource installation promise so if a rule runs before its resources are fully initialized, it will wait for initialization to complete before writing. ## To Verify The following rule registry contexts are affected: `observability.apm` `observability.logs` `observability.metrics` `observability.slo` `observability.uptime` `security` For each context, we should verify the following: `Note that if your rule context references the ECS mappings, there may be differences in those mappings between main and this branch depending on whether you're running main with enableFrameworkAlerts true or false. These differences are explained in the summary of this prior PR: #150384 but essentially we're aligning with the latest ECS fields. In the instructions, I suggest running main with enableFrameworkAlerts: true to minimize the differences caused by ECS changes` **While running `main` with `enableFrameworkAlerts: true`:** 1. Get the context specific component template `GET _component_template/.alerts-{context}.alerts-mappings` 2. Create rule for this context that creates an alert and then 3. Get the index template `GET _index_template/.alerts-{context}.alerts-default-index-template` 4. Get the index mapping for the concrete index: `GET .internal.alerts-{context}.alerts-default-000001/_mapping` **While running this branch with `xpack.alerting.enableFrameworkAlerts: true` (with a fresh ES instance):** 5. Get the context specific component template `GET _component_template/.alerts-{context}.alerts-mappings` 6. Get the index template `GET _index_template/.alerts-{context}.alerts-default-index-template` 7. Get the index mapping for the concrete index: `GET .internal.alerts-{context}.alerts-default-000001/_mapping` Note that you should not have to create a rule that generates alerts before seeing these resources installed. **Compare the component templates** Compare 1 and 5. The difference should be: * component template from this branch should have `_meta.managed: true`. This is a flag indicating to the user that these templates are system managed and should not be manually modified. **Compare the index templates** Compare 3 and 6. The differences should be: * index template from this branch should have `managed: true` in the `_meta` fields * index template from this branch should not have a `priority` field. This will be addressed in a followup PR * index template from this branch should be composed of `.alerts-legacy-alert-mappings` and `.alerts-framework-mappings` instead of `.alerts-technical-mappings` but under the hood, these mappings are equivalent. **Compare the index mappings** Compare 4 and 7. The difference should be: * index mappings from this branch should have `_meta.managed: true`. ### Verify that installed resources templates work as expected 1. Run this branch on a fresh ES install with `xpack.alerting.enableFrameworkAlerts: true`. 2. Create a rule in your context that generates alerts. 3. Verify that there are no errors during rule execution. 4. Verify that the alerts show up in your alerts table as expected. 5. (For detection rules only): Run this branch with `xpack.alerting.enableFrameworkAlerts: true` and verify rules in a non-default space continue to create resources on first rule run and run as expected. 6. (For detection rules only): Run this branch with `xpack.alerting.enableFrameworkAlerts: true` and verify rule preview continue to work as expected ### Verify that installed resources templates work with existing rule registry resources. 1. Run `main` or a previous version and create a rule in your context that generates alerts. 2. Using the same ES data, switch to this branch with `xpack.alerting.enableFrameworkAlerts: false` and verify Kibana starts with no rule registry errors and the rule continues to run as expected. 3. Using the same ES data, switch to this branch with `xpack.alerting.enableFrameworkAlerts: true` and verify Kibana starts with no alerting or rule registry errors and the rule continues to run as expected. 4. Verify the alerts show up on the alerts table as expected. 5. (For detection rules only): Run this branch with `xpack.alerting.enableFrameworkAlerts: true` and verify rules in a non-default space continue to create resources on first rule run and run as expected. 6. (For detection rules only): Run this branch with `xpack.alerting.enableFrameworkAlerts: true` and verify rule preview continue to work as expected --------- Co-authored-by: Kibana Machine <[email protected]>

…for framework alerts as data (elastic#150384) Resolves elastic#150358 ## Summary In a previous [PR](elastic#145581) we started installing a common component template for framework alerts as data when the `xpack.alerting.enableFrameworkAlerts` config flag is set to true. In that PR we used a different naming pattern than what is used by the rule registry for its component templates. In this PR we are doing the following: * Renaming the installed `alerts-common-component-template` to `.alerts-framework-mappings`. * Creating and installing `.alerts-legacy-alert-mappings` component template when `enableFrameworkAlerts: true` on alerting plugin setup * The combination of the two component templates creates the same set of mappings as the rule registry technical component template * Creating and installing `.alerts-ecs-mappings` component template when `enableFrameworkAlerts: true` on alerting plugin setup (when `enableFrameworkAlerts: false`, the rule registry continues to install this component template * Using the `@kbn/ecs` package provided by core to generate the ECS field map. The rule registry will continue to install the existing ECS field map which is actually a subset of ECS fields * Adding `useLegacy` and `useEcs` flags that allow rule types to specify whether to include the legacy alerts component template and the ECS component template when registering with framework alerts-as-data. * Moved some common functions to alerting framework from the rule registry ## Things to note * When generating the ECS field map, we are now including the `ignore_above` setting from the `@kbn/ecs` package. This changes the ECS component template to include those settings. I tested updating an index with just `"type":"keyword"` mappings to add the `ignore_above` field to the mapping and had no issues so this seems like an additive change to the mapping that will hopefully prevent problems in the future. * The rule registry ECS component template also includes the technical fields which is redundant because the technical component template is automatically installed for all index templates so the framework ECS component template only contains ECS fields. | Previous mapping | Updated mapping | | ----------- | ----------- | | `{ "organization": { "type": "keyword" } }` | `{ "organization": { "type": "keyword", "ignore_above": 1024 } }` | ## To Verify ### Verify that the generated component templates are as expected: Get the following **While running `main`:** 1. Get the ECS component template `GET _component_template/.alerts-ecs-mappings` 2. Get the technical component template `GET _component_template/.alerts-technical-mappings` 3. Create a detection rule that creates an alert and then get the index mapping for the concrete security alert index `GET .internal.alerts-security.alerts-default-000001/_mapping` **While running this branch with `xpack.alerting.enableFrameworkAlerts: false`:** 4. Get the ECS component template `GET _component_template/.alerts-ecs-mappings` 5. Get the technical component template `GET _component_template/.alerts-technical-mappings` 6. Create a detection rule that creates an alert and then get the index mapping for the concrete security alert index `GET .internal.alerts-security.alerts-default-000001/_mapping` **While running this branch with `xpack.alerting.enableFrameworkAlerts: true`:** 7. Get the ECS component template `GET _component_template/.alerts-ecs-mappings` 8. Get the technical component template `GET _component_template/.alerts-technical-mappings` 9. Create a detection rule that creates an alert and then get the index mapping for the concrete security alert index `GET .internal.alerts-security.alerts-default-000001/_mapping` 10. Verify that component templates exist for `.alerts-framework-mappings` and `.alerts-legacy-alert-mappings` **Compare the ECS component templates** Compare 1 and 4 (ECS component template from `main` and installed by rule registry in this branch). The difference should be: * no difference in ECS fields * because the rule registry ECS component template also includes technical fields, you will see the 2 new technical fields in this branch Compare 4 and 7 (ECS component template from rule registry & alerting framework in this branch). * some new ECS fields for alerting installed template * each `keyword` mapped field for alerting installed template should have `ignore_above` setting * no `kibana.*` fields in the alerting installed template **Compare the technical component templates** Compare 2 and 5 (technical component template from `main` and installed by rule registry in this branch). The difference should be: * 2 new `kibana.alert` fields (`flapping_history` and `last_detected`) Compare 5 and 8 (technical component template from rule registry & alerting framework in this branch). * there should be no difference! **Compare the index mappings** Compare 3 and 6 (index mapping from `main` and installed by rule registry in this branch). The difference should be: * 2 new `kibana.alert` fields (`flapping_history` and `last_detected`) Compare 6 and 9 (index mapping from rule registry & alerting framework in this branch). * some new ECS fields * each `keyword` mapped ECS field should have `ignore_above` setting ### Verify that the generated component templates work with existing rule registry index templates & indices: 1. Run `main` or a previous version and create a rule that uses both ECS component templates & technical component templates (detection rules use both). Let it run a few times. 2. Using the same ES data, switch to this branch with `xpack.alerting.enableFrameworkAlerts: false` and verify Kibana starts with no rule registry errors and the rule continues to run as expected. 3. Using the same ES data, switch to this branch with `xpack.alerting.enableFrameworkAlerts: true` and verify Kibana starts with no alerting or rule registry errors and the rule continues to run as expected. Verify that the mapping on the existing `.internal.alerts-security.alerts-default-000001` has been updated to include the latest ECS mappings and the two new technical fields. ### Checklist Delete any items that are not applicable to this PR. - [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 <[email protected]> Co-authored-by: Mike Côté <[email protected]>

…ponent templates, index templates and concrete write index to framework for alerts-as-data (elastic#151792) Resolves elastic#151697 ## Summary In a previous [PR](elastic#145581) we started installing a context-specific component templates, index templates and concrete write indices for framework alerts as data when the `xpack.alerting.enableFrameworkAlerts` config flag is set to true. In that PR we used a different naming pattern than what is used by the rule registry for those resources. In this PR, we are aligning the naming of these resources with the rule registry and installing these resources on alerting plugin setup when `enableFrameworkAlerts: true`. If the flag is set to false, the rule registry will continue to handle this resource installation. In this PR we are doing the following: * Registering all rules currently registered with the rule registry with the alerting framework. This registration allows the alerting framework to build context specific component templates. Because this PR only addresses resource installation, rules will continue to be registered with the rule registry. * When `enableFrameworkAlerts: true`: * The framework installs the context specific component template with the following naming convention: `.alerts-{context}.alerts-mappings`. This matches what the rule registry currently installs so the transition should be seamless * The framework installs the context specific index template for the `default` space with the following name: `.alerts-{context}.alerts-default-index-template`. Space awareness will be addressed in a followup PR. This matches the current rule registry naming.This index template will reference (1) ECS component template (if `useEcs: true`), (2) context-specific component template, (3) legacy alert component template and (4) framework component template where the legacy alert component template + framework component template = technical component template (from the rule registry). * The framework creates or updates the concrete write index for the `default` space with the naming convention: `.internal.alerts-{context}.alerts-default-000001`. Space awareness will be addressed in a followup PR. This matches the current rule registry naming. * The installation of the index template & write index differs from the rule registry in that it occurs on alerting plugin start vs the first rule run. * We modified the rule registry resource installer to skip installation of these resources when `enableFrameworkAlerts: true`. In addition, it will wait for the alerting resource installation promise so if a rule runs before its resources are fully initialized, it will wait for initialization to complete before writing. ## To Verify The following rule registry contexts are affected: `observability.apm` `observability.logs` `observability.metrics` `observability.slo` `observability.uptime` `security` For each context, we should verify the following: `Note that if your rule context references the ECS mappings, there may be differences in those mappings between main and this branch depending on whether you're running main with enableFrameworkAlerts true or false. These differences are explained in the summary of this prior PR: elastic#150384 but essentially we're aligning with the latest ECS fields. In the instructions, I suggest running main with enableFrameworkAlerts: true to minimize the differences caused by ECS changes` **While running `main` with `enableFrameworkAlerts: true`:** 1. Get the context specific component template `GET _component_template/.alerts-{context}.alerts-mappings` 2. Create rule for this context that creates an alert and then 3. Get the index template `GET _index_template/.alerts-{context}.alerts-default-index-template` 4. Get the index mapping for the concrete index: `GET .internal.alerts-{context}.alerts-default-000001/_mapping` **While running this branch with `xpack.alerting.enableFrameworkAlerts: true` (with a fresh ES instance):** 5. Get the context specific component template `GET _component_template/.alerts-{context}.alerts-mappings` 6. Get the index template `GET _index_template/.alerts-{context}.alerts-default-index-template` 7. Get the index mapping for the concrete index: `GET .internal.alerts-{context}.alerts-default-000001/_mapping` Note that you should not have to create a rule that generates alerts before seeing these resources installed. **Compare the component templates** Compare 1 and 5. The difference should be: * component template from this branch should have `_meta.managed: true`. This is a flag indicating to the user that these templates are system managed and should not be manually modified. **Compare the index templates** Compare 3 and 6. The differences should be: * index template from this branch should have `managed: true` in the `_meta` fields * index template from this branch should not have a `priority` field. This will be addressed in a followup PR * index template from this branch should be composed of `.alerts-legacy-alert-mappings` and `.alerts-framework-mappings` instead of `.alerts-technical-mappings` but under the hood, these mappings are equivalent. **Compare the index mappings** Compare 4 and 7. The difference should be: * index mappings from this branch should have `_meta.managed: true`. ### Verify that installed resources templates work as expected 1. Run this branch on a fresh ES install with `xpack.alerting.enableFrameworkAlerts: true`. 2. Create a rule in your context that generates alerts. 3. Verify that there are no errors during rule execution. 4. Verify that the alerts show up in your alerts table as expected. 5. (For detection rules only): Run this branch with `xpack.alerting.enableFrameworkAlerts: true` and verify rules in a non-default space continue to create resources on first rule run and run as expected. 6. (For detection rules only): Run this branch with `xpack.alerting.enableFrameworkAlerts: true` and verify rule preview continue to work as expected ### Verify that installed resources templates work with existing rule registry resources. 1. Run `main` or a previous version and create a rule in your context that generates alerts. 2. Using the same ES data, switch to this branch with `xpack.alerting.enableFrameworkAlerts: false` and verify Kibana starts with no rule registry errors and the rule continues to run as expected. 3. Using the same ES data, switch to this branch with `xpack.alerting.enableFrameworkAlerts: true` and verify Kibana starts with no alerting or rule registry errors and the rule continues to run as expected. 4. Verify the alerts show up on the alerts table as expected. 5. (For detection rules only): Run this branch with `xpack.alerting.enableFrameworkAlerts: true` and verify rules in a non-default space continue to create resources on first rule run and run as expected. 6. (For detection rules only): Run this branch with `xpack.alerting.enableFrameworkAlerts: true` and verify rule preview continue to work as expected --------- Co-authored-by: Kibana Machine <[email protected]>

ymao1 added 14 commits November 16, 2022 16:09

wip

e8581cf

wip

017676e

Got ECS and alert field maps ready. Generating and installing compone…

c241bbd

…nt templates

Fixing tsconfig

e2c4d3c

Fixing checks

df02fb4

Merge branch 'main' of https://github.com/elastic/kibana into alertin…

a061175

…g/faad-resources

Fixing checks

6b54cff

wip

7e02900

Merge branch 'main' of https://github.com/elastic/kibana into alertin…

c902075

…g/faad-resources

Adding desired schema

044e765

Merge branch 'main' of https://github.com/elastic/kibana into alertin…

6b40f3b

…g/faad-resources

Merge branch 'main' of https://github.com/elastic/kibana into alertin…

bdbbc3b

…g/faad-resources

Got schema generator working

128a575

Merge branch 'main' of https://github.com/elastic/kibana into alertin…

e708b19

…g/faad-resources

ymao1 added the ci:build-webpack-bundle-analyzer label Dec 6, 2022

ymao1 added 7 commits December 6, 2022 13:37

Cleaning up schema generation script and adding check to buildkite

64faa67

Trying to reduce bundle size

9bde6b3

Installing all the resources

5b95dd6

Merge branch 'main' of https://github.com/elastic/kibana into alertin…

2d8b3dc

…g/faad-resources

wip

5e5f4b7

Adding unit tests for alerts service

8ec92b5

Merge branch 'main' of https://github.com/elastic/kibana into alertin…

c3deb7f

…g/faad-resources

kibanamachine and others added 7 commits December 13, 2022 13:46

Merge branch 'main' into alerting/faad-resources

c48f2b1

Fixing types

60a750c

Merge branch 'main' of https://github.com/elastic/kibana into alertin…

063fdda

…g/faad-resources

Adding retries for transient ES errors and tests for installation tim…

32da96a

…eout

Merge branch 'main' of https://github.com/elastic/kibana into alertin…

453cd7b

…g/faad-resources

Merge branch 'main' of https://github.com/elastic/kibana into alertin…

cd0d3c2

…g/faad-resources

Fixing types

1d2e9d4

Merge branch 'main' of https://github.com/elastic/kibana into alertin…

4080def

…g/faad-resources

CoenWarmer approved these changes Jan 18, 2023

View reviewed changes

Merging in main

3ff7e81

pmuellr approved these changes Jan 19, 2023

View reviewed changes

kibanamachine and others added 2 commits January 23, 2023 08:03

Merge branch 'main' into alerting/faad-resources

0360c36

PR feedback

9d48b9f

ymao1 force-pushed the alerting/faad-resources branch from b113946 to cb680ef Compare January 23, 2023 14:27

Throwing error regardless

6b74e18

ymao1 force-pushed the alerting/faad-resources branch from cb680ef to 6b74e18 Compare January 23, 2023 14:56

Merging in main

19b8818

Merge branch 'main' into alerting/faad-resources

3d54034

ymao1 merged commit b7a0204 into elastic:main Jan 24, 2023

kibanamachine added the backport:skip This commit does not require backporting label Jan 24, 2023

This was referenced Feb 15, 2023

[Response Ops][Alerting] Update common component template generation for framework alerts as data #150384

Merged

[Response Ops][Alerting] Migrate installation of context-specific component templates, index templates & indices to alerting framework #151697

Closed

ymao1 mentioned this pull request Feb 27, 2023

[Response Ops][Alerting] Migrate installation of context-specific component templates, index templates and concrete write index to framework for alerts-as-data #151792

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Response Ops][Alerting] Install resources needed for framework alerts-as-data #145581

[Response Ops][Alerting] Install resources needed for framework alerts-as-data #145581

ymao1 commented Nov 17, 2022 •

edited

Loading

ymao1 commented Dec 13, 2022

CoenWarmer left a comment

pmuellr left a comment

pmuellr Jan 19, 2023

pmuellr Jan 19, 2023

pmuellr Jan 19, 2023

pmuellr Jan 19, 2023

ymao1 commented Jan 23, 2023

ymao1 commented Jan 24, 2023

kibana-ci commented Jan 24, 2023

API count

ESLint disabled line counts

Total ESLint disabled count

[Response Ops][Alerting] Install resources needed for framework alerts-as-data #145581

[Response Ops][Alerting] Install resources needed for framework alerts-as-data #145581

Conversation

ymao1 commented Nov 17, 2022 • edited Loading

Summary

Notes

To Verify

Checklist

ymao1 commented Dec 13, 2022

CoenWarmer left a comment

Choose a reason for hiding this comment

pmuellr left a comment

Choose a reason for hiding this comment

pmuellr Jan 19, 2023

Choose a reason for hiding this comment

pmuellr Jan 19, 2023

Choose a reason for hiding this comment

pmuellr Jan 19, 2023

Choose a reason for hiding this comment

pmuellr Jan 19, 2023

Choose a reason for hiding this comment

ymao1 commented Jan 23, 2023

ymao1 commented Jan 24, 2023

kibana-ci commented Jan 24, 2023

💚 Build Succeeded

Metrics [docs]

Module Count

Public APIs missing comments

Public APIs missing exports

API count

ESLint disabled line counts

Total ESLint disabled count

History

ymao1 commented Nov 17, 2022 •

edited

Loading