-
Notifications
You must be signed in to change notification settings - Fork 8.5k
[Security Solution][Detection Engine] adds async ES|QL query #216667
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
8fd25d5
a7724d9
957e85b
1ee4962
8a02d3c
0d3c168
ff2ab3b
4ac1d30
de0c6d2
df83947
79bc275
fa753e4
46f74e6
27e7f84
c681fd5
1be54cf
9a701e9
e874bd3
a78438d
423551c
dd6de17
1200aae
b53a8ef
066c9e4
7e67924
236e9da
e849de0
8b75f69
adc5ef8
4d37838
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -23,6 +23,7 @@ export interface BuildEqlSearchRequestParams { | |
| primaryTimestamp: TimestampOverride; | ||
| secondaryTimestamp: TimestampOverride | undefined; | ||
| exceptionFilter: Filter | undefined; | ||
| ruleExecutionTimeout: string | undefined; | ||
| } | ||
|
|
||
| export const buildEsqlSearchRequest = ({ | ||
|
|
@@ -34,6 +35,7 @@ export const buildEsqlSearchRequest = ({ | |
| secondaryTimestamp, | ||
| exceptionFilter, | ||
| size, | ||
| ruleExecutionTimeout, | ||
| }: BuildEqlSearchRequestParams) => { | ||
| const esFilter = getQueryFilter({ | ||
| query: '', | ||
|
|
@@ -61,5 +63,7 @@ export const buildEsqlSearchRequest = ({ | |
| filter: requestFilter, | ||
| }, | ||
| }, | ||
| wait_for_completion_timeout: '4m', // hard limit request timeout is 5m set by ES proxy and alerting framework. So, we should be fine to wait 4m for async query completion. If rule execution is shorter than 4m and query was not completed, it will be aborted. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. setting Setting
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, the idea was not to start polling until rule timeouts. If rule timeout is greater then 5m, when we can hit ES requests timeout limitation, we would stop waiting for query to complete(4m) and start polling.
We don't have access to rule timeout within executor - only to
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see, that makes sense. Is 4m the right value for both ECH and serverless? The default rule timeout is different for serverless, right? Is the default connection timeout different? I think it would be worth following up on this PR to see if we can get access to the rule timeout or maybe have the framework wrapper inject a
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Default rule timeout for serverless is 1m. If async query request runs longer that this, it would be aborted and query cancelled/deleted in ES.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @marshallmain , issue to expose rule timeout to rule executor: #218072
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds good, we'll just have to be aware of any timeout discrepancies in the future. If the rule timeout increases in serverless (which is a desirable change for us) but the connection timeout values are different (e.g. lower in serverless), we could start seeing environment specific failures.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think errors would be in the same category - timeout related. Can be just for different requests(query or poll) and different times. But, we already have different timeout for different envs |
||
| ...(ruleExecutionTimeout ? { keep_alive: ruleExecutionTimeout } : {}), | ||
| }; | ||
| }; | ||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really small, but in this wrapper we log the search duration. We may not want to log duration metrics for async searches bc the query times won't be accurate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have set wait_for_complete to 4m. So, query duration can be up to 4m., which is quite significant value.
And afterwards, we'll have polling requests that would help to build a whole picture of requests timings