[ML UI/AI Infra][9.3 & Serverless]: Anomaly Detection: Alerting rule filtering #4240
Conversation
✅ Vale Linting ResultsNo issues found on modified lines! |
benironside
left a comment
benironside
left a comment
There was a problem hiding this comment.
Nice work! Left a few suggestions for your consideration, I'm not an expert on this so take it with a grain of salt. If you decide to apply them to ml-configuring-alerts.md, you may want to also update create-an-anomaly-detection-rule.md
explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md
Outdated
Show resolved
Hide resolved
explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md
Outdated
Show resolved
Hide resolved
explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md
Outdated
Show resolved
Hide resolved
explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md
Outdated
Show resolved
Hide resolved
| 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. |
There was a problem hiding this comment.
| 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. | |
| 9. (Optional) Turn on **Include interim results** to include results created by the anomaly detection job *before* their 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. |
bmorelli25
left a comment
bmorelli25
left a comment
There was a problem hiding this comment.
I have some feedback on screenshots that you didn't ask for 😬 sorry!
| :::{image} /explore-analyze/images/ml-anomaly-create-anomaly-detection.png | ||
| :alt: Selecting Anomaly detection rule type | ||
| :screenshot: | ||
| ::: |
There was a problem hiding this comment.
I know you didn't add this (maybe you did previously?). I'm not sure this screenshot adds any value. The instruction for this line is short and to the point 2. Select the **{{anomaly-detect-cap}}** rule type.. What do you think about removing this screenshot?
There was a problem hiding this comment.
Agree with removing. I was thinking the same : )
| :::{image} /explore-analyze/images/ml-anomaly-alert.png | ||
| :alt: Selecting result type, severity, and interim results | ||
| :screenshot: | ||
| ::: |
There was a problem hiding this comment.
Whereas the previous screenshot felt too obvious to be needed, this one feels more confusing than helpful. I had to re-read step seven a few times before I saw the Include interim results toggle at the bottom.
Is this necessary? Why does step 7 get a screenshot when step 4 (Select a type of machine learning result. You can create rules based on bucket, record, or influencer results.), for example, does not?
There was a problem hiding this comment.
This is also very similar to solutions/images/serverless-anomaly-detection-alert.png, but different enough to mean we need to update two screenshots instead of one when they inevitably go stale.
There was a problem hiding this comment.
This is another interesting one. Of the three screenshots I've commented on, this is the one you could probably easiest convince me to stay. But that's mostly because it's pretty; It shows off the feature config which looks quite nice.
I'm curious how we use screenshots elsewhere. Is this the typical pattern? What I mean by that is that this screenshot is in step 5, but then applies to steps 6-14.
Admittedly, this is not my area of expertise. Would love to hear your thoughts and @florent-leborgne's.
There was a problem hiding this comment.
Reading this too but there's not much to go off of: https://docs.elastic.dev/tech-writing-guidelines/ui-writing#screenshots.
| * 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"`. |
…ing-alerts.md Co-authored-by: Benjamin Ironside Goldstein <91905639+benironside@users.noreply.github.com>
…ing-alerts.md Co-authored-by: Benjamin Ironside Goldstein <91905639+benironside@users.noreply.github.com>
…ing-alerts.md Co-authored-by: Benjamin Ironside Goldstein <91905639+benironside@users.noreply.github.com>
| * 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 |
There was a problem hiding this comment.
These are definitely the most important filters available for narrowing down the results, however, there are more fields you can filter by. I think it's okay, I'm just wondering whether it suggests that the only available fields are the ones mentioned.
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
Preview