Skip to content
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

Merged
merged 36 commits into from
Sep 9, 2020

Conversation

lizozom
Copy link
Contributor

@lizozom lizozom commented Aug 23, 2020

Summary

Depends on #75943
Partially resolves #75321
Related to #75385

  • Remove defaultVars from the legacy core_plugins/elasticsearch code and stop using esShardTimeout anyewhere on the client.
  • Introduce a new SEARCH_TIMEOUT uiSetting. This setting controls the search interceptor timing in xpack, while the OSS timeout behavior is now controlled by the server.
  • Remove unnecessary settings from the FE (and fetch them from uiSettings on the server)
  • Update the default search settings in getDefaultSearchParams
  • Fix a small bug: delete wasn't using the search strategy name properly.
  • Simplify the construction of arguments for async search.

Dev Docs

This PR changes the behavior of how we timeout search requests:

  • The Kibana server uses the new ES client. The client already uses all timeout configurations like requestTimeout, shardTimeout and maxRetries 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.
  • With Basic+ licenses, users can control the maximum time for a search session (for example a single re-load of a dashboard), per space. This PR introduces a new Advanced Setting that can be set to a positive value, or to 0, hence allowing queries to run without a timeout, as long as a user stays on screen.

Checklist

Delete any items that are not applicable to this PR.

For maintainers

@lizozom lizozom added the release_note:plugin_api_changes Contains a Plugin API changes section for the breaking plugin API changes section. label Aug 23, 2020
@lizozom lizozom requested a review from a team as a code owner August 23, 2020 15:41
@lizozom lizozom changed the title Add new x-pack advanced setting searchTimeout and use it in the Enhan… Add new x-pack advanced setting searchTimeout Aug 23, 2020
@lizozom lizozom changed the title Add new x-pack advanced setting searchTimeout Add new Basic+ advanced setting searchTimeout Aug 23, 2020
@lizozom lizozom self-assigned this Aug 23, 2020
@lizozom lizozom added Feature:Search Querying infrastructure in Kibana v7.10.0 v8.0.0 Team:AppArch labels Aug 23, 2020
@elasticmachine
Copy link
Contributor

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.',
Copy link
Member

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?

Copy link
Member

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).

Copy link
Contributor Author

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?

@lizozom lizozom marked this pull request as draft August 26, 2020 10:53
@lizozom
Copy link
Contributor Author

lizozom commented Aug 26, 2020

@elasticmachine merge upstream

@lizozom lizozom changed the title Add new Basic+ advanced setting searchTimeout [Search] Add a new advanced setting searchTimeout Aug 26, 2020
@lizozom
Copy link
Contributor Author

lizozom commented Aug 27, 2020

@elasticmachine merge upstream

Copy link
Member

@lukasolson lukasolson left a 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 used track_total_hits instead, and shimmed the response so it looked the same as when we send rest_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 the track_total_hits parameter and shim the response instead of sending rest_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.

@lizozom
Copy link
Contributor Author

lizozom commented Sep 1, 2020

@lukasolson I added maxConcurrentShardRequests to all types of search. I also used trackTotalHits instead of restTotalHitsAsInt and added a call to shimTotalHits in both search and msearch route handlers.

Copy link
Member

@lukasolson lukasolson left a 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]

@lizozom
Copy link
Contributor Author

lizozom commented Sep 2, 2020

@lukasolson "lost" is a nice way to say "attempted to intentionally remove".
Just reverted this change.

@lizozom
Copy link
Contributor Author

lizozom commented Sep 3, 2020

@elasticmachine merge upstream
@elasticmachine merge upstream

@lukasolson
Copy link
Member

@elasticmachine merge upstream

1 similar comment
@lizozom
Copy link
Contributor Author

lizozom commented Sep 6, 2020

@elasticmachine merge upstream

@lizozom
Copy link
Contributor Author

lizozom commented Sep 6, 2020

@elasticmachine merge upstream

1 similar comment
@lizozom
Copy link
Contributor Author

lizozom commented Sep 7, 2020

@elasticmachine merge upstream

Copy link
Contributor

@majagrubic majagrubic left a 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!

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Build metrics

page load bundle size

id value diff baseline
data 1.4MB -1.6KB 1.4MB
dataEnhanced 178.8KB +645.0B 178.1KB
visTypeVega 665.4KB -154.0B 665.5KB
total -1.1KB

distributable file count

id value diff baseline
default 45456 +2 45454
oss 27224 +2 27222
total +4

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@lizozom lizozom merged commit 52c12ea into elastic:master Sep 9, 2020
lizozom added a commit to lizozom/kibana that referenced this pull request Sep 9, 2020
* 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
lizozom added a commit that referenced this pull request Sep 9, 2020
* 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
gmmorris added a commit to gmmorris/kibana that referenced this pull request Sep 9, 2020
* 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)
  ...
FrankHassanabad added a commit that referenced this pull request Feb 11, 2021
…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
FrankHassanabad added a commit that referenced this pull request Feb 11, 2021
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Search Querying infrastructure in Kibana release_note:plugin_api_changes Contains a Plugin API changes section for the breaking plugin API changes section. v7.10.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Search] Update timeout configurations
6 participants