From 65535019ed221817d52d1f6155aa10a62817e4b8 Mon Sep 17 00:00:00 2001 From: Nastasha Solomon Date: Tue, 28 Oct 2025 15:23:34 -0400 Subject: [PATCH 1/6] First draft --- docs/en/observability/metrics-threshold-alert.asciidoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/en/observability/metrics-threshold-alert.asciidoc b/docs/en/observability/metrics-threshold-alert.asciidoc index e69648ebec..2fde9c893e 100644 --- a/docs/en/observability/metrics-threshold-alert.asciidoc +++ b/docs/en/observability/metrics-threshold-alert.asciidoc @@ -45,6 +45,8 @@ image::images/metrics-alert-filters-and-group.png[Metric threshold filter and gr The *Filters* control the scope of the rule. If used, the rule will only evaluate metric data that matches the query in this field. In this example, the rule will only alert on metrics reported from a Cloud region called `us-east`. +NOTE: Filters that you've added to the rule using the [create rule API](https://www.elastic.co/docs/api/doc/kibana/operation/operation-post-alerting-rule-id) won't display in the UI when you're editing a rule. If you want to modify them, you must manually re-add the filters by entering a KQL query in the rule's **Filter** field. + The *Group alerts by* creates an instance of the alert for every unique value of the `field` added. For example, you can create a rule per host or every mount point of each host. You can also add multiple fields. In this example, the rule will individually track the status of each `host.name` in your infrastructure. You will only receive an alert about `host-1`, if `host.name: host-1` passes the threshold, but `host-2` and `host-3` do not. When you select *Alert me if a group stops reporting data*, the rule is triggered if a group that previously reported metrics does not report them again over the expected time period. From cff2ba59ea1dc7a39feeb3c07ae5543cda32efa0 Mon Sep 17 00:00:00 2001 From: Nastasha Solomon Date: Tue, 28 Oct 2025 16:02:56 -0400 Subject: [PATCH 2/6] fix syntax --- docs/en/observability/metrics-threshold-alert.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/observability/metrics-threshold-alert.asciidoc b/docs/en/observability/metrics-threshold-alert.asciidoc index 2fde9c893e..ad18dd0cdf 100644 --- a/docs/en/observability/metrics-threshold-alert.asciidoc +++ b/docs/en/observability/metrics-threshold-alert.asciidoc @@ -45,7 +45,7 @@ image::images/metrics-alert-filters-and-group.png[Metric threshold filter and gr The *Filters* control the scope of the rule. If used, the rule will only evaluate metric data that matches the query in this field. In this example, the rule will only alert on metrics reported from a Cloud region called `us-east`. -NOTE: Filters that you've added to the rule using the [create rule API](https://www.elastic.co/docs/api/doc/kibana/operation/operation-post-alerting-rule-id) won't display in the UI when you're editing a rule. If you want to modify them, you must manually re-add the filters by entering a KQL query in the rule's **Filter** field. +NOTE: Filters that you've added to the rule using the (https://www.elastic.co/docs/api/doc/kibana/operation/operation-post-alerting-rule-id)[create rule API] won't display in the UI when you're editing a rule. If you want to modify them, you must manually re-add the filters by entering a KQL query in the rule's **Filter** field. The *Group alerts by* creates an instance of the alert for every unique value of the `field` added. For example, you can create a rule per host or every mount point of each host. You can also add multiple fields. In this example, the rule will individually track the status of each `host.name` in your infrastructure. You will only receive an alert about `host-1`, if `host.name: host-1` passes the threshold, but `host-2` and `host-3` do not. From 79146a8567c5450e2c42375e1dbec40fb3a195f7 Mon Sep 17 00:00:00 2001 From: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com> Date: Thu, 30 Oct 2025 15:18:09 -0400 Subject: [PATCH 3/6] Update docs/en/observability/metrics-threshold-alert.asciidoc --- docs/en/observability/metrics-threshold-alert.asciidoc | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/en/observability/metrics-threshold-alert.asciidoc b/docs/en/observability/metrics-threshold-alert.asciidoc index ad18dd0cdf..d8a01c8795 100644 --- a/docs/en/observability/metrics-threshold-alert.asciidoc +++ b/docs/en/observability/metrics-threshold-alert.asciidoc @@ -45,7 +45,10 @@ image::images/metrics-alert-filters-and-group.png[Metric threshold filter and gr The *Filters* control the scope of the rule. If used, the rule will only evaluate metric data that matches the query in this field. In this example, the rule will only alert on metrics reported from a Cloud region called `us-east`. -NOTE: Filters that you've added to the rule using the (https://www.elastic.co/docs/api/doc/kibana/operation/operation-post-alerting-rule-id)[create rule API] won't display in the UI when you're editing a rule. If you want to modify them, you must manually re-add the filters by entering a KQL query in the rule's **Filter** field. +NOTE: If you've made a rule with the (https://www.elastic.co/docs/api/doc/kibana/operation/operation-post-alerting-rule-id)[create rule API] and added Query DSL filters using the `filterQuery` parameter, the filters won't appear in the UI for editing a rule. As a workaround, manually re-add the filters through the UI and save the rule. As you're modifying the rule's filters from the UI, be mindful of the following: + + - The **Filter** field only accepts KQL syntax, meaning you may need to manually convert your Query DSL filters to KQL. + - After you save the rule, filters you've added to the **Filter** field are converted appropriately and specified in the rule's `filterQuery` parameter. The *Group alerts by* creates an instance of the alert for every unique value of the `field` added. For example, you can create a rule per host or every mount point of each host. You can also add multiple fields. In this example, the rule will individually track the status of each `host.name` in your infrastructure. You will only receive an alert about `host-1`, if `host.name: host-1` passes the threshold, but `host-2` and `host-3` do not. From ea1e52536389f1edb964705a8687e4cf1f0af5f5 Mon Sep 17 00:00:00 2001 From: Nastasha Solomon Date: Thu, 30 Oct 2025 15:19:49 -0400 Subject: [PATCH 4/6] no spaces! --- docs/en/observability/metrics-threshold-alert.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/en/observability/metrics-threshold-alert.asciidoc b/docs/en/observability/metrics-threshold-alert.asciidoc index d8a01c8795..e058579340 100644 --- a/docs/en/observability/metrics-threshold-alert.asciidoc +++ b/docs/en/observability/metrics-threshold-alert.asciidoc @@ -47,8 +47,8 @@ The *Filters* control the scope of the rule. If used, the rule will only evaluat NOTE: If you've made a rule with the (https://www.elastic.co/docs/api/doc/kibana/operation/operation-post-alerting-rule-id)[create rule API] and added Query DSL filters using the `filterQuery` parameter, the filters won't appear in the UI for editing a rule. As a workaround, manually re-add the filters through the UI and save the rule. As you're modifying the rule's filters from the UI, be mindful of the following: - - The **Filter** field only accepts KQL syntax, meaning you may need to manually convert your Query DSL filters to KQL. - - After you save the rule, filters you've added to the **Filter** field are converted appropriately and specified in the rule's `filterQuery` parameter. +- The **Filter** field only accepts KQL syntax, meaning you may need to manually convert your Query DSL filters to KQL. +- After you save the rule, filters you've added to the **Filter** field are converted appropriately and specified in the rule's `filterQuery` parameter. The *Group alerts by* creates an instance of the alert for every unique value of the `field` added. For example, you can create a rule per host or every mount point of each host. You can also add multiple fields. In this example, the rule will individually track the status of each `host.name` in your infrastructure. You will only receive an alert about `host-1`, if `host.name: host-1` passes the threshold, but `host-2` and `host-3` do not. From a82c75e6c7c08b1539d939f656d478422738d269 Mon Sep 17 00:00:00 2001 From: Nastasha Solomon Date: Thu, 30 Oct 2025 15:35:28 -0400 Subject: [PATCH 5/6] block --- docs/en/observability/metrics-threshold-alert.asciidoc | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/en/observability/metrics-threshold-alert.asciidoc b/docs/en/observability/metrics-threshold-alert.asciidoc index e058579340..a72389a328 100644 --- a/docs/en/observability/metrics-threshold-alert.asciidoc +++ b/docs/en/observability/metrics-threshold-alert.asciidoc @@ -45,11 +45,15 @@ image::images/metrics-alert-filters-and-group.png[Metric threshold filter and gr The *Filters* control the scope of the rule. If used, the rule will only evaluate metric data that matches the query in this field. In this example, the rule will only alert on metrics reported from a Cloud region called `us-east`. -NOTE: If you've made a rule with the (https://www.elastic.co/docs/api/doc/kibana/operation/operation-post-alerting-rule-id)[create rule API] and added Query DSL filters using the `filterQuery` parameter, the filters won't appear in the UI for editing a rule. As a workaround, manually re-add the filters through the UI and save the rule. As you're modifying the rule's filters from the UI, be mindful of the following: +[NOTE] +===== +If you've made a rule with the (https://www.elastic.co/docs/api/doc/kibana/operation/operation-post-alerting-rule-id)[create rule API] and added Query DSL filters using the `filterQuery` parameter, the filters won't appear in the UI for editing a rule. As a workaround, manually re-add the filters through the UI and save the rule. As you're modifying the rule's filters from the UI, be mindful of the following: - The **Filter** field only accepts KQL syntax, meaning you may need to manually convert your Query DSL filters to KQL. - After you save the rule, filters you've added to the **Filter** field are converted appropriately and specified in the rule's `filterQuery` parameter. +===== + The *Group alerts by* creates an instance of the alert for every unique value of the `field` added. For example, you can create a rule per host or every mount point of each host. You can also add multiple fields. In this example, the rule will individually track the status of each `host.name` in your infrastructure. You will only receive an alert about `host-1`, if `host.name: host-1` passes the threshold, but `host-2` and `host-3` do not. When you select *Alert me if a group stops reporting data*, the rule is triggered if a group that previously reported metrics does not report them again over the expected time period. From e31f46b28c5a571879a64b123ffb34c2863b1257 Mon Sep 17 00:00:00 2001 From: Nastasha Solomon Date: Thu, 30 Oct 2025 17:21:55 -0400 Subject: [PATCH 6/6] removed un-needed parenth --- docs/en/observability/metrics-threshold-alert.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/observability/metrics-threshold-alert.asciidoc b/docs/en/observability/metrics-threshold-alert.asciidoc index a72389a328..2fa452525d 100644 --- a/docs/en/observability/metrics-threshold-alert.asciidoc +++ b/docs/en/observability/metrics-threshold-alert.asciidoc @@ -47,7 +47,7 @@ The *Filters* control the scope of the rule. If used, the rule will only evaluat [NOTE] ===== -If you've made a rule with the (https://www.elastic.co/docs/api/doc/kibana/operation/operation-post-alerting-rule-id)[create rule API] and added Query DSL filters using the `filterQuery` parameter, the filters won't appear in the UI for editing a rule. As a workaround, manually re-add the filters through the UI and save the rule. As you're modifying the rule's filters from the UI, be mindful of the following: +If you've made a rule with the https://www.elastic.co/docs/api/doc/kibana/operation/operation-post-alerting-rule-id[create rule API] and added Query DSL filters using the `filterQuery` parameter, the filters won't appear in the UI for editing a rule. As a workaround, manually re-add the filters through the UI and save the rule. As you're modifying the rule's filters from the UI, be mindful of the following: - The **Filter** field only accepts KQL syntax, meaning you may need to manually convert your Query DSL filters to KQL. - After you save the rule, filters you've added to the **Filter** field are converted appropriately and specified in the rule's `filterQuery` parameter.