diff --git a/explore-analyze/images/ml-anomaly-alert.jpg b/explore-analyze/images/ml-anomaly-alert.jpg deleted file mode 100644 index 0f76fb20f8..0000000000 Binary files a/explore-analyze/images/ml-anomaly-alert.jpg and /dev/null differ diff --git a/explore-analyze/images/ml-anomaly-alert.png b/explore-analyze/images/ml-anomaly-alert.png new file mode 100644 index 0000000000..72edb82c42 Binary files /dev/null and b/explore-analyze/images/ml-anomaly-alert.png differ diff --git a/explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md b/explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md index 19fa5c2dea..9d487753c5 100644 --- a/explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md +++ b/explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md @@ -56,19 +56,32 @@ To set up an {{anomaly-detect}} alert rule: 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. +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 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 creating the KQL query, you're given suggestions for the most relevant fields to filter by. To compare actual and typical values, use operators such as `>` (greater than), `<` (less than), or `=` (equal to). + :::: + +7. 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 +:::{image} /explore-analyze/images/ml-anomaly-alert.png :alt: Selecting result type, severity, and interim results :screenshot: ::: -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 +99,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. diff --git a/solutions/images/serverless-anomaly-detection-alert.png b/solutions/images/serverless-anomaly-detection-alert.png index acf67aa4e0..391dd3cc24 100644 Binary files a/solutions/images/serverless-anomaly-detection-alert.png and b/solutions/images/serverless-anomaly-detection-alert.png differ diff --git a/solutions/observability/incident-management/create-an-anomaly-detection-rule.md b/solutions/observability/incident-management/create-an-anomaly-detection-rule.md index e3436de6a5..d727d6e591 100644 --- a/solutions/observability/incident-management/create-an-anomaly-detection-rule.md +++ b/solutions/observability/incident-management/create-an-anomaly-detection-rule.md @@ -50,18 +50,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 monitors for, add an **Anomaly filter**. This filtering capability uses KQL and is only available for the Record and Influencer result types. + + In the **Anomaly filter** field, enter a KQL query that specifies to only alert when either or both happen: + + * Certain partitioning or influencers fields in the anomaly results match 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 creating the KQL query, you're given suggestions for the most relevant fields to filter by. To compare actual and typical values, 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 if you want to be notified earlier about a potential anomaly even if it might be a false positive. + +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.