[ML UI/AI Infra][9.3 & Serverless]: Anomaly Detection: Alerting rule filtering (#4240)

## Summary
Fixes #4145. By explaining
how to use the new **Anomaly filter** field to narrow down the list of
anomalies that ML anomaly detection rules check for. Also refreshes
outdated screenshots.

## Generative AI disclosure
1. Did you use a generative AI (GenAI) tool to assist in creating this
contribution?
- [ ] Yes  
- [x] No  

## Preview
- [Observability anomaly detection
rule](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4240/solutions/observability/incident-management/create-an-anomaly-detection-rule)
- Step 6 is new
- [Stack anomaly detection
rule](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/4240/explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts#creating-anomaly-alert-rules)
- Step 8 is new

---------

Co-authored-by: Benjamin Ironside Goldstein <[email protected]>

Author: nastasha-solomon

explore-analyze/images/ml-anomaly-alert.jpg

@@ -45,30 +45,28 @@ To set up an {{anomaly-detect}} alert rule:
 1. Open **{{rules-ui}}**: find **{{stack-manage-app}} > {{rules-ui}}** in the main menu or use the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md).
 2. Select the **{{anomaly-detect-cap}}** rule type.
 
-:::{image} /explore-analyze/images/ml-anomaly-create-anomaly-detection.png
-:alt: Selecting Anomaly detection rule type
-:screenshot:
-:::
-
 3. Select the [{{anomaly-job}}](/explore-analyze/machine-learning/anomaly-detection/ml-ad-run-jobs.md) that the rule applies to.
 4. Select a type of {{ml}} result. You can create rules based on bucket, record, or influencer results.
 5. (Optional) Configure the `anomaly_score` that triggers the action. 
 The `anomaly_score` indicates the significance of a given anomaly compared to 
 previous anomalies. The default severity threshold is 75 which means every 
 anomaly with an `anomaly_score` of 75 or higher triggers the associated action.
-6. Select whether you want to include interim results. Interim results are created before a bucket is finalized and might disappear after full processing.
-    - Include interim results if you 
-want to be notified earlier about a potential anomaly even if it might be a 
-false positive. 
-    - Don't include interim results if you want to get notified only about anomalies of fully 
-processed buckets.
-
-:::{image} /explore-analyze/images/ml-anomaly-alert.jpg
-:alt: Selecting result type, severity, and interim results
-:screenshot:
-:::
+6. {applies_to}`stack: ga 9.3`{applies_to}`serverless: ga` (Optional) To narrow down the list of anomalies that the rule looks for, add an **Anomaly filter**. This feature uses KQL and is only available for the Record and Influencer result types.
+    
+    In the **Anomaly filter** field, enter a KQL query that specifies fields or conditions to alert on. You can set up the following conditions:
+    
+    * One or more partitioning or influencers fields in the anomaly results match the specified conditions
+    * The actual or typical scores in the anomalies match the specified conditions
+
+    For example, say you've set up alerting for an anomaly detection job that has `partition_field = "response.keyword"` as the detector. If you were only interested in being alerted on `response.keyword = 404`, enter `partition_field_value: "404"` into the **Anomaly filter** field. When the rule runs, it will only alert on anomalies with `partition_field_value: "404"`.
+
+    ::::{note}
+    When you edit the KQL query, suggested filter-by fields appear. To compare actual and typical values for any fields, use operators such as `>` (greater than), `<` (less than), or `=` (equal to).
+    ::::
+
+7. (Optional) Turn on **Include interim results** to include results that are created by the anomaly detection job *before* a bucket is finalized. These results might disappear after the bucket is fully processed. Include interim results to get notified earlier about potential anomalies, even if they might be false positives. Don't include interim results if you want to get notified only about anomalies of fully processed buckets.
 
-7. (Optional) Configure **Advanced settings**:
+8. (Optional) Configure **Advanced settings**:
    - Configure the _Lookback interval_ to define how far back to query previous anomalies during each condition check. Its value is derived from the bucket span of the job and the query delay of the {{dfeed}} by default. It is not recommended to set the lookback interval lower than the default value, as it might result in missed anomalies.
    - Configure the _Number of latest buckets_ to specify how many buckets to check to obtain the highest anomaly score found during the _Lookback interval_. The alert is created based on the highest scoring anomaly from the most anomalous bucket.
 
@@ -86,8 +84,8 @@ You can preview how the rule would perform on existing data:
 :screenshot:
 :::
 
-8. Set how often to check the rule conditions by selecting a time value and unit under **Rule schedule**.
-9. (Optional) Configure **Advanced options**:
+9. Set how often to check the rule conditions by selecting a time value and unit under **Rule schedule**.
+10. (Optional) Configure **Advanced options**:
    - Define the number of consecutive matches required before an alert is triggered under **Alert delay**.
    - Enable or disable **Flapping Detection** to reduce noise from frequently changing alerts. You can customize the flapping detection settings if you need different thresholds for detecting flapping behavior.
 

explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md

@@ -34,14 +34,8 @@ To create an anomaly detection rule:
 2. In the list of anomaly detection jobs, find the job you want to check for anomalies. Haven’t created a job yet? [Create one now](/explore-analyze/machine-learning/anomaly-detection.md).
 3. From the **Actions** menu next to the job, select **Create alert rule**.
 4. Specify a name and optional tags for the rule. You can use these tags later to filter alerts.
-5. Verify that the correct job is selected and configure the alert details:
-
-    :::{image} /solutions/images/serverless-anomaly-detection-alert.png
-    :alt: Anomaly detection alert settings
-    :screenshot:
-    :::
-
-6. For the result type:
+5. Verify that the correct job is selected or select a new one.
+6. Select a type of machine learning result:
 
     | Choose… | To generate an alert based on… |
     | --- | --- |
@@ -50,18 +44,32 @@ To create an anomaly detection rule:
     | **Influencer** | The most unusual entities in a time range |
 
 7. Adjust the **Severity** to match the anomaly score that will trigger the action. The anomaly score indicates the significance of a given anomaly compared to previous anomalies. The default severity threshold is 75, which means every anomaly with an anomaly score of 75 or higher will trigger the associated action.
-8. (Optional) Turn on **Include interim results** to include results that are created by the anomaly detection job *before* a bucket is finalized. These results might disappear after the bucket is fully processed. Include interim results if you want to be notified earlier about a potential anomaly even if it might be a false positive.
-9. (Optional) Expand and change **Advanced settings**:
+8. {applies_to}`stack: ga 9.3`{applies_to}`serverless: ga` (Optional) To narrow down the list of anomalies that the rule looks for, add an **Anomaly filter**. This feature uses KQL and is only available for the Record and Influencer result types.
+    
+    In the **Anomaly filter** field, enter a KQL query that specifies fields or conditions to alert on. You can set up the following conditions:
+    
+    * One or more partitioning or influencers fields in the anomaly results match the specified conditions
+    * The actual or typical scores in the anomalies match specified conditions
+
+    For example, say you've set up alerting for an anomaly detection job that has `partition_field = "response.keyword"` as the detector. If you were only interested in being alerted on `response.keyword = 404`, enter `partition_field_value: "404"` into the **Anomaly filter** field. When the rule runs, it will only alert on anomalies with `partition_field_value: "404"`.
+
+    ::::{note}
+    When you edit the KQL query, suggested filter-by fields appear. To compare actual and typical values for any fields, use operators such as `>` (greater than), `<` (less than), or `=` (equal to).
+    ::::
+
+9. (Optional) Turn on **Include interim results** to include results that are created by the anomaly detection job *before* a bucket is finalized. These results might disappear after the bucket is fully processed. Include interim results to get notified earlier about potential anomalies, even if they might be false positives. Don't include interim results if you want to get notified only about anomalies of fully processed buckets.
+
+10. (Optional) Expand and change **Advanced settings**:
 
     | Setting | Description |
     | --- | --- |
     | **Lookback interval** | The interval used to query previous anomalies during each condition check. Setting the lookback interval lower than the default value might result in missed anomalies. |
     | **Number of latest buckets** | The number of buckets to check to obtain the highest anomaly from all the anomalies that are found during the Lookback interval. An alert is created based on the anomaly with the highest anomaly score from the most anomalous bucket. |
 
-10. (Optional) Under **Check the rule condition with an interval**, specify an interval, then click **Test** to check the rule condition with the interval specified. The button is grayed out if the datafeed is not started. To test the rule, start the data feed.
-11. (Optional) If you want to change how often the condition is evaluated, adjust the **Check every** setting.
-12. (Optional) Set up **Actions**.
-13. **Save** your rule.
+11. (Optional) Under **Check the rule condition with an interval**, specify an interval, then click **Test** to check the rule condition with the interval specified. The button is grayed out if the datafeed is not started. To test the rule, start the data feed.
+12. (Optional) If you want to change how often the condition is evaluated, adjust the **Check every** setting.
+13. (Optional) Set up **Actions**.
+14. **Save** your rule.
 
 ::::{note}
 Anomaly detection rules are defined as part of a job. Alerts generated by these rules do not appear on the **Alerts** page.