[Alerting] Search alert #88528
[Alerting] Search alert #88528
Conversation
… index popoover into component for reuse between index threshold and es query alert types
… against doc count
…ing/search-alert
…ing/search-alert
…r every document if threshold is not defined
…ing/search-alert
…pression components
…ing/search-alert
…ing/search-alert
…ing/search-alert
…ing/search-alert
…ing/search-alert
…ing/search-alert
…ing/search-alert
|
I think this implementation works. I like simply having text that shows the result of the test. It's right next to the test button and toasts tend to cover the flyout buttons anyway. |
x-pack/plugins/stack_alerts/public/alert_types/es_query/expression.tsx
Outdated
Show resolved
Hide resolved
|
@elasticmachine merge upstream |
| // During each alert execution, we run the configured query, get a hit count | ||
| // (hits.total) and retrieve up to DEFAULT_MAX_HITS_PER_EXECUTION hits. We | ||
| // evaluate the threshold condition using the value of hits.total. If the threshold | ||
| // condition is met, the hits are counted toward the query match and we update |
There was a problem hiding this comment.
I wonder if we should call this alert "query threshold" instead of "query". At some point, we'll probably need to create a completely generic query alert, no threshold, no windowing, just whatever the customer wants to query for, and presumably provide the complete ES response in a context variable.
| // evaluate the threshold condition using the value of hits.total. If the threshold | ||
| // condition is met, the hits are counted toward the query match and we update | ||
| // the alert state with the timestamp of the latest hit. In the next execution | ||
| // of the alert, the latestTimestamp will be used to gate the query in order to |
There was a problem hiding this comment.
Problem with this is it will miss documents which got ingested late. Eg, alert runs at 12:00. A document gets added at 12:01, but it's actual date (being queried over) is 11:59. The alert would presumably never see it.
Since we already have the "window" parameters like other alerts, I wonder if we just shouldn't do this at all. Eg, we could do the same for index threshold, but don't. Should we?
There was a problem hiding this comment.
That's an interesting point. I based this logic off of how the Detection Rule Threshold Alert works. I can ask them how they handle this type of scenario.
|
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]Module Count
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |
* Adding es query alert type to server with commented out executor * Adding skeleton es query alert to client with JSON editor. Pulled out index popoover into component for reuse between index threshold and es query alert types * Implementing alert executor that performs query and matches condition against doc count * Added tests for server side alert type * Updated alert executor to de-duplicate matches and create instance for every document if threshold is not defined * Moving more index popover code out of index threshold and es query expression components * Ability to remove threshold condition from es query alert * Validation tests * Adding ability to test out query. Need to add error handling and it looks ugly * Fixing bug with creating alert with threshold and i18n * wip * Fixing tests * Simplifying executor logic to only handle threshold and store hits in action context * Adding functional test for es query alert * Types * Adding functional test for query testing * Fixing unit test * Adding link to ES docs. Cleaning up logger statements * Adding docs * Updating docs based on feedback * PR fixes * Using ES client typings * Fixing unit test * Fixing copy based on comments * Fixing copy based on comments * Fixing bug in index select popover * Fixing unit tests * Making track_total_hits configurable * Fixing functional test * PR fixes * Added unit test * Removing unused import Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
|
@ymao1 Thank you this is extremely mega cool. ❤️ |
* [Alerting] Search alert (#88528) * Adding es query alert type to server with commented out executor * Adding skeleton es query alert to client with JSON editor. Pulled out index popoover into component for reuse between index threshold and es query alert types * Implementing alert executor that performs query and matches condition against doc count * Added tests for server side alert type * Updated alert executor to de-duplicate matches and create instance for every document if threshold is not defined * Moving more index popover code out of index threshold and es query expression components * Ability to remove threshold condition from es query alert * Validation tests * Adding ability to test out query. Need to add error handling and it looks ugly * Fixing bug with creating alert with threshold and i18n * wip * Fixing tests * Simplifying executor logic to only handle threshold and store hits in action context * Adding functional test for es query alert * Types * Adding functional test for query testing * Fixing unit test * Adding link to ES docs. Cleaning up logger statements * Adding docs * Updating docs based on feedback * PR fixes * Using ES client typings * Fixing unit test * Fixing copy based on comments * Fixing copy based on comments * Fixing bug in index select popover * Fixing unit tests * Making track_total_hits configurable * Fixing functional test * PR fixes * Added unit test * Removing unused import Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> * Fixing typings * Fixing query to use ISO string instead of millis Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
mikecote
added
release_note:feature
|
I'll echo that last comment, extremely mega mega cool. I can't say how excited I am about this alert type and the functionality it unlocks! I also have to applaud you @ymao1 for the detail in the PR description. That takes time. As someone who isn't able to follow as closely, I was able to clearly understand what this PR provided. So, thanks for taking the time to share the details 👏👏👏 |
Resolves #61313
Summary
New stack alert for executing ES DSL (query only, no aggregation support) and evaluating the number of matches against a threshold condition.
UI
Alert params expression contains a JSON editor allowing users to enter query DSL and test their query. Screenshots attached.
Search alert in alert types list
Search alert params
Test query success
Test query failure
Alert executor
Each run of the alert executor builds an ES query with the user-defined query clause and the user defined time window relative to the date/time of the alert execution. In order to avoid counting a single document multiple times during multiple executions of the alert, we keep track of the timestamp of the last document that matched a threshold condition. This is passed through the alert state and used during the next execution as an additional filter for the query.
Action context
Matching documents are passed through to actions using
context.hits. This can be used with mustache templates to create a message for each matching document containing information about that document.Resulting Slack Notification
Docs
Documentation
Checklist
Delete any items that are not applicable to this PR.