From 893ab42f59ed03a3488dc16698d940a137cdfda0 Mon Sep 17 00:00:00 2001 From: "nastasha.solomon" Date: Wed, 17 Jul 2024 09:30:23 -0400 Subject: [PATCH] Vitalii's input --- docs/detections/alert-suppression.asciidoc | 4 ++-- docs/detections/rules-ui-create.asciidoc | 2 +- docs/serverless/alerts/alert-suppression.mdx | 4 ++-- docs/serverless/rules/rules-ui-create.mdx | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/detections/alert-suppression.asciidoc b/docs/detections/alert-suppression.asciidoc index de0ba0b820..c49cb28ee0 100644 --- a/docs/detections/alert-suppression.asciidoc +++ b/docs/detections/alert-suppression.asciidoc @@ -42,13 +42,13 @@ You can configure alert suppression when you create or edit a supported rule typ If you specify a field with multiple values, alerts with that field are handled as follows: * **Custom query or threshold rules:** A group of alerts is created for each value. For example, if you suppress alerts by `destination.ip` of `[127.0.0.1, 127.0.0.2, 127.0.0.3]`, alerts will be suppressed separately for each value of `127.0.0.1`, `127.0.0.2`, and `127.0.0.3`. -* **Indicator match rule, event correlation (non-sequence queries only), new terms, or {esql} rule:** Alerts with the specified field name and identical array values are grouped together. For example, if you suppress alerts by `destination.ip` of `[127.0.0.1, 127.0.0.2, 127.0.0.3]`, alerts with the entire array are grouped and only one alert is created for the group. +* **Indicator match rule, event correlation (non-sequence queries only), new terms, {esql}, or {ml} rule:** Alerts with the specified field name and identical array values are grouped together. For example, if you suppress alerts by `destination.ip` of `[127.0.0.1, 127.0.0.2, 127.0.0.3]`, alerts with the entire array are grouped and only one alert is created for the group. ====== . If available, select how often to create alerts for duplicate events: + -NOTE: Both options are available for custom query, indicator match, event correlation, and new terms rules. Threshold rules only have the *Per time period* option. +NOTE: Both options are available for custom query, indicator match, event correlation, new terms, {esql}, and {ml} rules. Threshold rules only have the *Per time period* option. + -- * *Per rule execution*: Create an alert each time the rule runs and meets its criteria. diff --git a/docs/detections/rules-ui-create.asciidoc b/docs/detections/rules-ui-create.asciidoc index 8e300763cc..fff8475118 100644 --- a/docs/detections/rules-ui-create.asciidoc +++ b/docs/detections/rules-ui-create.asciidoc @@ -471,7 +471,7 @@ If the `LIMIT` value and **Max alerts per run** value are different, the rule us - When writing an aggregating query, use the {ref}/esql-commands.html#esql-stats-by[`STATS...BY`] command with fields that you want to search and filter for after alerts are created. For example, using the `host.name`, `user.name`, `process.name` fields with the `BY` operator of the `STATS...BY` command returns these fields in alert documents, and allows you to search and filter for them from the Alerts table. -- When configuring alert suppression on a non-aggregating query, avoid sorting alerts by descending `@timestamp` order. Doing so can impact the number of alerts that are suppressed, especially if the number of alerts generated is higher than the maximum number of alerts the rule can create when it runs. +- When configuring alert suppression on a non-aggregating query, we recommend sorting results by ascending `@timestamp` order. Doing so ensures that alerts are properly suppressed, especially if the number of alerts generated is higher than the **Max alerts per run** value. [float] [[esql-rule-limitations]] diff --git a/docs/serverless/alerts/alert-suppression.mdx b/docs/serverless/alerts/alert-suppression.mdx index 159ba52d66..4a49d30118 100644 --- a/docs/serverless/alerts/alert-suppression.mdx +++ b/docs/serverless/alerts/alert-suppression.mdx @@ -44,14 +44,14 @@ You can configure alert suppression when you create or edit a supported rule typ If you specify a field with multiple values, alerts with that field are handled as follows: * **Custom query or threshold rules:** Alerts are grouped by each unique value. For example, if you suppress alerts by `destination.ip` of `[127.0.0.1, 127.0.0.2, 127.0.0.3]`, alerts will be suppressed separately for each value of `127.0.0.1`, `127.0.0.2`, and `127.0.0.3`. - * **Indicator match, event correlation (non-sequence queries only), new terms, or ((esql)) rule:** Alerts with the specified field name and identical array values are grouped together. For example, if you suppress alerts by `destination.ip` of `[127.0.0.1, 127.0.0.2, 127.0.0.3]`, alerts with the entire array are grouped and only one alert is created for the group. + * **Indicator match, event correlation (non-sequence queries only), new terms, ((esql)), or ((ml)) rule:** Alerts with the specified field name and identical array values are grouped together. For example, if you suppress alerts by `destination.ip` of `[127.0.0.1, 127.0.0.2, 127.0.0.3]`, alerts with the entire array are grouped and only one alert is created for the group. 1. If available, select how often to create alerts for duplicate events: - Both options are available for custom query, indicator match, event correlation, and new terms rules. Threshold rules only have the **Per time period** option. + Both options are available for custom query, indicator match, event correlation, new terms, ((esql)), and ((ml)) rules. Threshold rules only have the **Per time period** option. * **Per rule execution**: Create an alert each time the rule runs and an event meets its criteria. diff --git a/docs/serverless/rules/rules-ui-create.mdx b/docs/serverless/rules/rules-ui-create.mdx index 5535747062..4b4e8b154a 100644 --- a/docs/serverless/rules/rules-ui-create.mdx +++ b/docs/serverless/rules/rules-ui-create.mdx @@ -504,7 +504,7 @@ When writing your query, consider the following: - When writing an aggregating query, use the [`STATS...BY`](((ref))/esql-commands.html#esql-stats-by) command with fields that you want to search and filter for after alerts are created. For example, using the `host.name`, `user.name`, `process.name` fields with the `BY` operator of the `STATS...BY` command returns these fields in alert documents, and allows you to search and filter for them from the Alerts table. -- When configuring alert suppression on a non-aggregating query, avoid sorting alerts by descending `@timestamp` order. Doing so can impact the number of alerts that are suppressed, especially if the number of alerts generated is higher than the maximum number of alerts the rule can create when it runs. +-- When configuring alert suppression on a non-aggregating query, we recommend sorting results by ascending `@timestamp` order. Doing so ensures that alerts are properly suppressed, especially if the number of alerts generated is higher than the **Max alerts per run** value.