88 lines
4.5 KiB
Plaintext
88 lines
4.5 KiB
Plaintext
[[kuery-query]]
|
|
=== Kibana Query Language Enhancements
|
|
|
|
experimental[This functionality is experimental and may be changed or removed completely in a future release.]
|
|
|
|
[NOTE]
|
|
============
|
|
In 6.0 we introduced an experimental query language called Kuery. We've taken what we learned from that experiment
|
|
and applied it to the standard Kibana query language. As a result, Kuery is no longer available as a standalone
|
|
option. Saved searches using Kuery will automatically be opted in to using the language enhancements described on
|
|
this page. However, some breaking changes have been made to the query syntax, so read on for the full details on
|
|
what's new.
|
|
============
|
|
|
|
Starting in 6.3, you can choose to opt-in to a number of exciting experimental query language enhancements under the
|
|
options menu in the query bar. Currently, opting in will enable scripted field support and a simplified, easier to
|
|
use syntax. If you have a Basic license or above, autocomplete functionality will also be enabled. We're hard at
|
|
work building even more features for you to try out. Take these features for a spin and let us know what you think!
|
|
|
|
==== New Simplified Syntax
|
|
|
|
If you're familiar with Kibana's old lucene query syntax, you should feel right at home with the new syntax. The basics
|
|
stay the same, we've simply refined things to make the query language easier to use. Read about the changes below.
|
|
|
|
`response:200` will match documents where the response field matches the value 200.
|
|
|
|
Quotes around a search term will initiate a phrase search. For example, `message:"Quick brown fox"` will search
|
|
for the phrase "quick brown fox" in the message field. Without the quotes, your query will get broken down into tokens via
|
|
the message field's configured analyzer and will match documents that contain those tokens, regardless of the order in which
|
|
they appear. This means documents with "quick brown fox" will match, but so will "quick fox brown". Remember to use quotes if you want
|
|
to search for a phrase.
|
|
|
|
The query parser will no longer split on whitespace. Multiple search terms must be separated by explicit
|
|
boolean operators. Note that boolean operators are not case sensitive.
|
|
|
|
`response:200 extension:php` in lucene would become `response:200 and extension:php`.
|
|
This will match documents where response matches 200 and extension matches php.
|
|
|
|
We can make terms optional by using `or`.
|
|
|
|
`response:200 or extension:php` will match documents where response matches 200, extension matches php, or both.
|
|
|
|
By default, `and` has a higher precedence than `or`.
|
|
|
|
`response:200 and extension:php or extension:css` will match documents where response is 200 and extension is php OR documents where extension is css and response is anything.
|
|
|
|
We can override the default precedence with grouping.
|
|
|
|
`response:200 and (extension:php or extension:css)` will match documents where response is 200 and extension is either php or css.
|
|
|
|
A shorthand exists that allows us to easily search a single field for multiple values.
|
|
|
|
`response:(200 or 404)` searches for docs where the `response` field matches 200 or 404. We can also search for docs
|
|
with multi-value fields that contain a list of terms, for example: `tags:(success and info and security)`
|
|
|
|
Terms can be inverted by prefixing them with `not`.
|
|
|
|
`not response:200` will match all documents where response is not 200.
|
|
|
|
Entire groups can also be inverted.
|
|
|
|
`response:200 and not (extension:php or extension:css)`
|
|
|
|
Ranges are similar to lucene with a small syntactical difference.
|
|
|
|
Instead of `bytes:>1000`, we omit the colon: `bytes > 1000`.
|
|
|
|
`>, >=, <, <=` are all valid range operators.
|
|
|
|
Exist queries are simple and do not require a special operator. `response:*` will find all docs where the response
|
|
field exists.
|
|
|
|
Wildcard queries are available. `machine.os:win*` would match docs where the machine.os field starts with "win", which
|
|
would match values like "windows 7" and "windows 10".
|
|
|
|
Wildcards also allow us to search multiple fields at once. This can come in handy when you have both `text` and `keyword`
|
|
versions of a field. Let's say we have `machine.os` and `machine.os.keyword` fields and we want to check both for the term
|
|
"windows 10". We can do it like this: `machine.os*:windows 10".
|
|
|
|
|
|
[NOTE]
|
|
============
|
|
Terms without fields will be matched against the default field in your index settings. If a default field is not
|
|
set these terms will be matched against all fields. For example, a query for `response:200` will search for the value 200
|
|
in the response field, but a query for just `200` will search for 200 across all fields in your index.
|
|
============
|
|
|