Add a switch to disallow slow queries

[jpountz]

It has been requested a couple times that we add a switch to disable the use of slow queries. This is typically useful to administrators who would like to prevent some users from using most resources on a cluster.

What a slow query is still needs to be refined but I think we could start with the following definition:

• multi-term queries that don't enforce at least the 5 first chars (eg. prefix queries with a length < 5, fuzzy queries, wildcard queries with a wildcard within the first 5 chars)
• geo-shape queries
• join queries
• script queries

Basically this tries to include all queries that cannot efficiently skip and that need to collect all matches in a bitset to return an iterator. Plus the script query because if you run it on its own it will need to look at every single document of the index.

The threshold of 5 means that you could still run arbitrary prefix queries on fields that use the index_prefix optimization with default configuration.

Relates #11511

[elasticmachine]

Pinging @elastic/es-search-aggs

[cbuescher]

What a slow query is still needs to be refined

I talked to a user just recently and they built their own solution for sth. similar (I think it was a plugin) that basically intercepts each search request, inspects the query tree and then rejects some queries by a customizable rule that is application-dependent. Maybe this is too flexible for a start but might be worth thinking about later or as an alternative.

[jpountz]

We discussed this in the search meeting and agreed on the following points:

• this sounds useful
• we want to start simple - finer-grained tuning will be done in follow-ups
• the way it is wired should make it easy to bind the right to execute slow queries with roles of the logged user in the future

[anelson-vidscale]

How about a knob that requires user confirmation if a dashboard is opened with a time range larger than the knob specified date range? For example, I don't have any dashboards where looking back more than 3 weeks makes sense. I do have some indices where looking back 3 months makes sense.

Another, orthogonal option is to have a cancel button for every Kibana visualization/dashboard.
In general, the users are not malicious, and most of them are educated. In my experience the problem is accidental and the user realizes his mistake immediately and wishes there was a cancel button.

[jpountz]

Another, orthogonal option is to have a cancel button for every Kibana visualization/dashboard.

FYI this is being somehow handled via #43332, which we plan to integrate in Kibana so that e.g. moving to a different window would cancel the loading of visualizations.