Searching your data
You can search the indices that match the current index pattern by entering your search criteria in the Query bar. By default you can use Kibana’s standard query language which features autocomplete and a simple, easy to use syntax. Kibana’s legacy query language (based on Lucene query syntax) is still available for the time being under the options menu in the Query Bar. When this legacy query language is selected, the full JSON-based Elasticsearch Query DSL can also be used.
When you submit a search request, the histogram, Documents table, and Fields list are updated to reflect the search results. The total number of hits (matching documents) is shown in the toolbar. The Documents table shows the first five hundred hits. By default, the hits are listed in reverse chronological order, with the newest documents shown first. You can reverse the sort order by clicking the Time column header. You can also sort the table by the values in any indexed field. For more information, see Sorting the Documents Table.
To search your data, enter your search criteria in the Query bar and press Enter or click Search search button to submit the request to Elasticsearch.
Kibana Query Language
In Kibana 6.3, we introduced a number of exciting experimental query language enhancements. These features are now available by default in 7.0. Out of the box, Kibana’s query language now includes scripted field support and a simplified, easier to use syntax. If you have a Basic license or above, autocomplete functionality will also be enabled.
Language 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".
