-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Search] Add a new advanced setting searchTimeout #75728
[Search] Add a new advanced setting searchTimeout #75728
Conversation
Pinging @elastic/kibana-app-arch (Team:AppArch) |
value: 600000, | ||
description: i18n.translate('kbn.advancedSettings.searchTimeoutDesc', { | ||
defaultMessage: | ||
'Change the maximum timeout for a search session or set to 0 to disable the timeout and allow queries to run to completion.', |
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.
I don't know "search timeout" is the right way to name this... it sounds very generic for a concept that is in my mind quite specific to async search & search sessions. (I also wouldn't expect an end user to understand what "search session" means)
That said, I'm struggling to think of better ideas. Maybe something like "grouped searches timeout" or "batched searches timeout"? IDK, but wanted to ask in case others have ideas.
How do we explain search sessions to a user? How do we make it clear that this isn't just a generic timeout for all searches?
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.
I think asyncSearchTimeout
would be more explicit. It's not actually the timeout per session, it's the timeout per async search (even though a single async search may consist of multiple requests).
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.
@lukasolson we actually talked about making it the session timeout, didn't we?
@elasticmachine merge upstream |
@elasticmachine merge upstream |
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'll need to add docs for this setting to the asciidocs too: https://github.com/elastic/kibana/blob/630d2d5fad9e08df4c8898efbd47f1a5f09575bf/docs/management/advanced-options.asciidoc
Here's some notes from my testing so far:
- At some point during development of async search, the
rest_total_hits_as_int
parameter wasn't working (for _async_search), so we usedtrack_total_hits
instead, and shimmed the response so it looked the same as when we sendrest_total_hits_as_int
. Well, it looks like now async search can handle this parameter. Regardless, I think the temporary solution should be to always send thetrack_total_hits
parameter and shim the response instead of sendingrest_total_hits_as_int
, since that parameter is deprecated and being removed in 8.0. (See [Kibana App] Adapt to new hits.total format in Elasticsearch #26356.) This can be tackled in a separate PR. max_concurrent_shard_requests
is only currently sent in _msearch. It could (and should) be sent in all of the scenarios we discussed (_search, _msearch, _rollup_search, and _async_search). I think this wasn't properly handled prior to this PR either.
I have a little bit more testing to do tomorrow but that's my feedback on what I've tested thus far.
@lukasolson I added maxConcurrentShardRequests to all types of search. I also used |
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.
Looks like at some point we lost the snake casing of parameters... I'm getting this error:
request [/aw-watcher-*/_async_search] contains unrecognized parameters: [batchedReduceSize] -> did you mean [batched_reduce_size]?, [ignoreThrottled] -> did you mean [ignore_throttled]?, [ignoreUnavailable] -> did you mean [ignore_unavailable]?, [keepAlive], [trackTotalHits], [waitForCompletionTimeout]
@lukasolson "lost" is a nice way to say "attempted to intentionally remove". |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
1 similar comment
@elasticmachine merge upstream |
@elasticmachine merge upstream |
1 similar comment
@elasticmachine merge upstream |
…bana into search/search-timeout-setting
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.
kibana-app code LGTM!
💚 Build SucceededBuild metricspage load bundle size
distributable file count
History
To update your PR or re-run it, just comment with: |
* Add new x-pack advanced setting searchTimeout and use it in the EnhancedSearchInterceptor * docs * Rely on server timeout in OSS (?) Use UI setting in xpack. * Rename function * doc * Remove esShard from client * cleanup request parameters from FE * doc * doc * Align request parameters on server, Remove leftover parameters from client Shim responses for search and msearch routes * docs Stop using toSnakeCase Updates jest tests * add management docs * docs * Remove import * Break circular dep + fix msearch test * Remove deleted type * Fix jest * Bring toSnakeCase back * docs * fix jest * Fix merge * Fix types * Allow timeout to be undefined * Fix jest test * Upldate docs * Fix msearch jest * docs * Fix rollup search merge * docs Co-authored-by: Lukas Olson <olson.lukas@gmail.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> # Conflicts: # src/legacy/core_plugins/elasticsearch/index.js
* Add new x-pack advanced setting searchTimeout and use it in the EnhancedSearchInterceptor * docs * Rely on server timeout in OSS (?) Use UI setting in xpack. * Rename function * doc * Remove esShard from client * cleanup request parameters from FE * doc * doc * Align request parameters on server, Remove leftover parameters from client Shim responses for search and msearch routes * docs Stop using toSnakeCase Updates jest tests * add management docs * docs * Remove import * Break circular dep + fix msearch test * Remove deleted type * Fix jest * Bring toSnakeCase back * docs * fix jest * Fix merge * Fix types * Allow timeout to be undefined * Fix jest test * Upldate docs * Fix msearch jest * docs * Fix rollup search merge * docs Co-authored-by: Lukas Olson <olson.lukas@gmail.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> # Conflicts: # src/legacy/core_plugins/elasticsearch/index.js
* master: (68 commits) a11y tests on spaces home page including feature control (elastic#76515) [ML] Transforms list: persist pagination through refresh interval (elastic#76786) [ML] Replace all use of date_histogram interval with fixed_interval (elastic#76876) [Timelion] Update timelion deprecation links (elastic#77008) [Security Solution] Refactor Network Details to use Search Strategy (elastic#76928) Upgrade elastic charts to 21.1.2 (elastic#76939) [Alerting][Connectors] Refactor Jira: Generic Implementation (phase one) (elastic#73778) [Snapshot & Restore] fix pre existing policy with no existing repository (elastic#76861) Update saved object management UI text (elastic#76826) [Form lib] Add validations prop to UseArray and expose "moveItem" handler (elastic#76949) [Logs UI] Use fields api in log stream (elastic#76919) [UI Metrics] Support multi-colon keys (elastic#76913) [APM] Script for creating functional test archive (elastic#76926) [ENDPOINT] First version of the trusted apps list. (elastic#76304) Correct field for rum page url (elastic#76916) [Security Solution] Fix redirect properly old SIEM App routes (elastic#76868) Bump http-proxy from 1.17.0 to 1.18.1 (elastic#76924) [RUM Dashboard] Visitor breakdown usability (elastic#76834) [Search] Add a new advanced setting searchTimeout (elastic#75728) [DOCS] Adds timelion deprecation to new visualize docs structure (elastic#76959) ...
…arch strategy (#91068) ## Summary Moves `track_total_hits` from body messages of our queries into the params section of our queries. Several of our `track_total_hits: false` were not taking effect and instead were being set to `track_total_hits: true` when being executed within the Kibana search strategy vs. previously when they were regular Elasticsearch queries and always took effect. When teams port over their searches to the search strategies provided by Kibana, they are required to move any and all `track_total_hits` from their `body` sections of their code into the `params` part of their code. The reason for this is that the search strategy maintains a backwards compatibility with earlier versions of searches before Elasticsearch introduced the `track_total_hits`. However, the code does not detect if you put the `track_total_hits` in your body, it only checks the params section and forces it to `true` if it is not found in the params section. If the search strategy does not see a `track_total_hits` within the params section of the query, it will force add one and that one will override any within the body of the query. For example, if you had a `track_total_hits` in your body and not in the params section, then search strategy would execute the query like so: ```ts GET someindex-*/_search?track_total_hits=true { // some query here "track_total_hits": false } ``` The forced parameter of `?track_total_hits=true` overrides the `track_total_hits: false` within the body of your query regardless of what the `track_total_hits` is set to and you always get the true. This bug has existed since 7.10.0 when we ported over queries to search strategy. You can see the code which sets this parameter if you do not here for master, 7.11, 7.10: https://github.com/elastic/kibana/blob/master/src/plugins/data/server/search/es_search/request_utils.ts#L31 https://github.com/elastic/kibana/blob/7.11/src/plugins/data/server/search/es_search/request_utils.ts#L31 https://github.com/elastic/kibana/blob/7.10/src/plugins/data/server/search/es_search/get_default_search_params.ts#L42 Comments about the behavior from 7.10: #75728 (review) When running this code you can open dev tools and inspect the data and now notice when the total hits does not get set vs. before when it was getting set: before fix where total shows up for queries with `track_total_hits` in the body: <img width="1370" alt="event_view_before" src="https://user-images.githubusercontent.com/1151048/107594265-bfc92e80-6bce-11eb-8526-8a9aa24e7b3a.png"> after fix where total no longer shows up for queries with `track_total_hits` moved to the params section: <img width="1309" alt="event_view_after" src="https://user-images.githubusercontent.com/1151048/107594274-c5bf0f80-6bce-11eb-9d8e-698ed430c953.png"> ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
…arch strategy (#91068) (#91076) ## Summary Moves `track_total_hits` from body messages of our queries into the params section of our queries. Several of our `track_total_hits: false` were not taking effect and instead were being set to `track_total_hits: true` when being executed within the Kibana search strategy vs. previously when they were regular Elasticsearch queries and always took effect. When teams port over their searches to the search strategies provided by Kibana, they are required to move any and all `track_total_hits` from their `body` sections of their code into the `params` part of their code. The reason for this is that the search strategy maintains a backwards compatibility with earlier versions of searches before Elasticsearch introduced the `track_total_hits`. However, the code does not detect if you put the `track_total_hits` in your body, it only checks the params section and forces it to `true` if it is not found in the params section. If the search strategy does not see a `track_total_hits` within the params section of the query, it will force add one and that one will override any within the body of the query. For example, if you had a `track_total_hits` in your body and not in the params section, then search strategy would execute the query like so: ```ts GET someindex-*/_search?track_total_hits=true { // some query here "track_total_hits": false } ``` The forced parameter of `?track_total_hits=true` overrides the `track_total_hits: false` within the body of your query regardless of what the `track_total_hits` is set to and you always get the true. This bug has existed since 7.10.0 when we ported over queries to search strategy. You can see the code which sets this parameter if you do not here for master, 7.11, 7.10: https://github.com/elastic/kibana/blob/master/src/plugins/data/server/search/es_search/request_utils.ts#L31 https://github.com/elastic/kibana/blob/7.11/src/plugins/data/server/search/es_search/request_utils.ts#L31 https://github.com/elastic/kibana/blob/7.10/src/plugins/data/server/search/es_search/get_default_search_params.ts#L42 Comments about the behavior from 7.10: #75728 (review) When running this code you can open dev tools and inspect the data and now notice when the total hits does not get set vs. before when it was getting set: before fix where total shows up for queries with `track_total_hits` in the body: <img width="1370" alt="event_view_before" src="https://user-images.githubusercontent.com/1151048/107594265-bfc92e80-6bce-11eb-8526-8a9aa24e7b3a.png"> after fix where total no longer shows up for queries with `track_total_hits` moved to the params section: <img width="1309" alt="event_view_after" src="https://user-images.githubusercontent.com/1151048/107594274-c5bf0f80-6bce-11eb-9d8e-698ed430c953.png"> ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
Summary
Depends on #75943
Partially resolves #75321
Related to #75385
defaultVars
from the legacycore_plugins/elasticsearch
code and stop usingesShardTimeout
anyewhere on the client.SEARCH_TIMEOUT
uiSetting
. This setting controls the search interceptor timing in xpack, while the OSS timeout behavior is now controlled by the server.getDefaultSearchParams
Dev Docs
This PR changes the behavior of how we timeout search requests:
requestTimeout
,shardTimeout
andmaxRetries
and since the client can't override those settings anyway, in OSS, we are removing the code governing the ES timeout on the client. Instead, this PR adds handling for a timeout error response.A nice side effect is being able to remove
injectDefaultVars
from the legacy core plugin.Checklist
Delete any items that are not applicable to this PR.
For maintainers