diff --git a/docs/dev-tools/console/console.asciidoc b/docs/dev-tools/console/console.asciidoc index 7cef9376330623..731290fea22d0c 100644 --- a/docs/dev-tools/console/console.asciidoc +++ b/docs/dev-tools/console/console.asciidoc @@ -1,7 +1,7 @@ [[console-kibana]] == Console -Console enables you to interact with the REST API of {es}. You can: +*Console* enables you to interact with the REST API of {es}. You can: * Send requests to {es} and view the responses * View API documentation @@ -12,13 +12,13 @@ To get started, open the main menu, click *Dev Tools*, then click *Console*. [role="screenshot"] image::dev-tools/console/images/console.png["Console"] -NOTE: You are unable to interact with the REST API of {kib} with the Console. +NOTE: You cannot to interact with the REST API of {kib} with the Console. [float] [[console-api]] === Write requests -Console understands commands in a cURL-like syntax. +*Console* understands commands in a cURL-like syntax. For example, the following is a `GET` request to the {es} `_search` API. [source,js] @@ -43,8 +43,8 @@ curl -XGET "http://localhost:9200/_search" -d' }' ---------------------------------- -When you paste the command into Console, {kib} automatically converts it -to Console syntax. Alternatively, if you want to see Console syntax in cURL, +When you paste the command into *Console*, {kib} automatically converts it +to *Console* syntax. Alternatively, if you want to see *Console* syntax in cURL, click the action icon (image:dev-tools/console/images/wrench.png[]) and select *Copy as cURL*. Once copied, the username and password will need to be provided for the calls to work from external environments. @@ -53,7 +53,7 @@ for the calls to work from external environments. [[console-autocomplete]] ==== Autocomplete -When you're typing a command, Console makes context-sensitive suggestions. +When you're typing a command, *Console* makes context-sensitive suggestions. These suggestions show you the parameters for each API and speed up your typing. To configure your preferences for autocomplete, go to <>. @@ -69,15 +69,16 @@ and then select *Auto indent*. For example, you might have a request formatted like this: [role="screenshot"] -image::dev-tools/console/images/copy-curl.png["Console close-up"] +image::dev-tools/console/images/copy-curl.png["Console close-up", width=75%] +] -Console adjusts the JSON body of the request to apply the indents. +*Console* adjusts the JSON body of the request to apply the indents. [role="screenshot"] -image::dev-tools/console/images/request.png["Console close-up"] +image::dev-tools/console/images/request.png["Console close-up", width=75%] If you select *Auto indent* on a request that is already well formatted, -Console collapses the request body to a single line per document. +*Console* collapses the request body to a single line per document. This is helpful when working with the {es} {ref}/docs-bulk.html[bulk APIs]. @@ -90,8 +91,9 @@ When you're ready to submit the request to {es}, click the green triangle. You can select multiple requests and submit them together. -Console sends the requests to {es} one by one and shows the output -in the response pane. Submitting multiple request is helpful when you're debugging an issue or trying query +*Console* sends the requests to {es} one by one and shows the output +in the response pane. Submitting multiple requests is helpful +when you're debugging an issue or trying query combinations in multiple scenarios. @@ -107,7 +109,7 @@ the action icon (image:dev-tools/console/images/wrench.png[]) and select [[console-history]] === Get your request history -Console maintains a list of the last 500 requests that {es} successfully executed. +*Console* maintains a list of the last 500 requests that {es} successfully executed. To view your most recent requests, click *History*. If you select a request and click *Apply*, {kib} adds it to the editor at the current cursor position. @@ -115,11 +117,11 @@ and click *Apply*, {kib} adds it to the editor at the current cursor position. [[configuring-console]] === Configure Console settings -You can configure the Console font size, JSON syntax, +You can configure the *Console* font size, JSON syntax, and autocomplete suggestions in *Settings*. [role="screenshot"] -image::dev-tools/console/images/console-settings.png["Console Settings"] +image::dev-tools/console/images/console-settings.png["Console Settings", width=60%] [float] [[keyboard-shortcuts]] @@ -132,7 +134,7 @@ shortcuts, click *Help*. [[console-settings]] === Disable Console -If you don’t want to use Console, you can disable it by setting `console.enabled` +If you don’t want to use *Console*, you can disable it by setting `console.enabled` to `false` in your `kibana.yml` configuration file. Changing this setting causes the server to regenerate assets on the next startup, which might cause a delay before pages start being served. diff --git a/docs/dev-tools/console/images/console.png b/docs/dev-tools/console/images/console.png index 0511ed858d1c3a..88f069388ea676 100644 Binary files a/docs/dev-tools/console/images/console.png and b/docs/dev-tools/console/images/console.png differ diff --git a/docs/dev-tools/console/images/copy-curl.png b/docs/dev-tools/console/images/copy-curl.png index 4811c1d24bfb86..a6fb9cd1438f47 100644 Binary files a/docs/dev-tools/console/images/copy-curl.png and b/docs/dev-tools/console/images/copy-curl.png differ diff --git a/docs/dev-tools/console/images/request.png b/docs/dev-tools/console/images/request.png index a8332434ec1865..c95b54dc95b0ac 100644 Binary files a/docs/dev-tools/console/images/request.png and b/docs/dev-tools/console/images/request.png differ diff --git a/docs/dev-tools/grokdebugger/images/grok-debugger-custom-pattern.png b/docs/dev-tools/grokdebugger/images/grok-debugger-custom-pattern.png index 2cb6f1dbf7226f..2a1660c860b4b4 100644 Binary files a/docs/dev-tools/grokdebugger/images/grok-debugger-custom-pattern.png and b/docs/dev-tools/grokdebugger/images/grok-debugger-custom-pattern.png differ diff --git a/docs/dev-tools/grokdebugger/images/grok-debugger-overview.png b/docs/dev-tools/grokdebugger/images/grok-debugger-overview.png index b6e9b734b307e3..4692c7a8020673 100644 Binary files a/docs/dev-tools/grokdebugger/images/grok-debugger-overview.png and b/docs/dev-tools/grokdebugger/images/grok-debugger-overview.png differ diff --git a/docs/dev-tools/grokdebugger/index.asciidoc b/docs/dev-tools/grokdebugger/index.asciidoc index 82ae724f705f65..934452c54ccca6 100644 --- a/docs/dev-tools/grokdebugger/index.asciidoc +++ b/docs/dev-tools/grokdebugger/index.asciidoc @@ -1,19 +1,19 @@ [role="xpack"] [[xpack-grokdebugger]] -== Debugging grok expressions +== Debug grok expressions You can build and debug grok patterns in the {kib} *Grok Debugger* -before you use them in your data processing pipelines. Grok is a pattern +before you use them in your data processing pipelines. Grok is a pattern matching syntax that you can use to parse arbitrary text and structure it. Grok is good for parsing syslog, apache, and other webserver logs, mysql logs, and in general, any log format that is -written for human consumption. +written for human consumption. Grok patterns are supported in the ingest node {ref}/grok-processor.html[grok processor] and the Logstash -{logstash-ref}/plugins-filters-grok.html[grok filter]. See +{logstash-ref}/plugins-filters-grok.html[grok filter]. See {logstash-ref}/plugins-filters-grok.html#_grok_basics[grok basics] -for more information on the syntax for a grok pattern. +for more information on the syntax for a grok pattern. The Elastic Stack ships with more than 120 reusable grok patterns. See @@ -27,10 +27,10 @@ in ingest node and Logstash. [float] [[grokdebugger-getting-started]] -=== Getting started with the Grok Debugger +=== Get started This example walks you through using the *Grok Debugger*. This tool -is automatically enabled in {kib}. +is automatically enabled in {kib}. NOTE: If you're using {stack-security-features}, you must have the `manage_pipeline` permission to use the Grok Debugger. @@ -66,12 +66,12 @@ image::dev-tools/grokdebugger/images/grok-debugger-overview.png["Grok Debugger"] [float] [[grokdebugger-custom-patterns]] -=== Testing custom patterns +=== Test custom patterns If the default grok pattern dictionary doesn't contain the patterns you need, -you can define, test, and debug custom patterns using the Grok Debugger. +you can define, test, and debug custom patterns using the *Grok Debugger*. -Custom patterns that you enter in the Grok Debugger are not saved. Custom patterns +Custom patterns that you enter in the *Grok Debugger* are not saved. Custom patterns are only available for the current debugging session and have no side effects. Follow this example to define a custom pattern. diff --git a/docs/dev-tools/painlesslab/images/painless-lab.png b/docs/dev-tools/painlesslab/images/painless-lab.png index fbfd54f69954dd..65b4141ed5c547 100644 Binary files a/docs/dev-tools/painlesslab/images/painless-lab.png and b/docs/dev-tools/painlesslab/images/painless-lab.png differ diff --git a/docs/dev-tools/painlesslab/index.asciidoc b/docs/dev-tools/painlesslab/index.asciidoc index 5e329843843ec1..7b4e9101a99013 100644 --- a/docs/dev-tools/painlesslab/index.asciidoc +++ b/docs/dev-tools/painlesslab/index.asciidoc @@ -4,7 +4,7 @@ beta::[] -The Painless Lab is an interactive code editor that lets you test and +The *Painless Lab* is an interactive code editor that lets you test and debug {ref}/modules-scripting-painless.html[Painless scripts] in real-time. You can use the Painless scripting language to create <>, @@ -12,6 +12,7 @@ process {ref}/docs-reindex.html[reindexed data], define complex <>, and work with data in other contexts. -To get started, open the main menu, click *Dev Tools*, then click *Painless Lab*. +To get started, open the main menu, click *Dev Tools*, and then click *Painless Lab*. +[role="screenshot"] image::dev-tools/painlesslab/images/painless-lab.png[Painless Lab] diff --git a/docs/dev-tools/searchprofiler/getting-started.asciidoc b/docs/dev-tools/searchprofiler/getting-started.asciidoc deleted file mode 100644 index ad73d03bcbfd8a..00000000000000 --- a/docs/dev-tools/searchprofiler/getting-started.asciidoc +++ /dev/null @@ -1,49 +0,0 @@ -[role="xpack"] -[[profiler-getting-started]] -=== Getting Started - -The {searchprofiler} is automatically enabled in {kib}. Open the main menu, click *Dev Tools*, then click *{searchprofiler}* -to get started. - -{searchprofiler} displays the names of the indices searched, the shards in each index, -and how long it took for the query to complete. To try it out, replace the default `match_all` query -with the query you want to profile and click *Profile*. - -The following example shows the results of profiling the `match_all` query. -If we take a closer look at the information for the `.kibana_1` sample index, the -Cumulative Time field shows us that the query took 1.279ms to execute. - -[role="screenshot"] -image::dev-tools/searchprofiler/images/overview.png["{searchprofiler} example"] - - -[NOTE] -==== -The Cumulative Time metric is the sum of individual shard times. -It is not necessarily the actual time it took for the query to return (wall clock time). -Because shards might be processed in parallel on multiple nodes, the wall clock time can -be significantly less than the Cumulative Time. However, if shards are colocated on the -same node and executed serially, the wall clock time is closer to the Cumulative Time. - -While the Cumulative Time metric is useful for comparing the performance of your -indices and shards, it doesn't necessarily represent the actual physical query times. -==== - -You can select the name of the shard and then click *View details* to see more profiling information, -including details about the query component(s) that ran on the shard, as well as the timing -breakdown of low-level Lucene methods. For more information, see {ref}/search-profile.html#profiling-queries[Profiling queries]. - -[float] -=== Index and type filtering - -By default, all queries executed by the {searchprofiler} are sent -to `GET /_search`. It searches across your entire cluster (all indices, all types). - -If you need to query a specific index or type (or several), you can use the Index -and Type filters. - -In the following example, the query is executed against the indices `test` and `kibana_1` -and the type `my_type`. This is equivalent making a request to `GET /test,kibana_1/my_type/_search`. - -[role="screenshot"] -image::dev-tools/searchprofiler/images/filter.png["Filtering by index and type"] diff --git a/docs/dev-tools/searchprofiler/gs-index.asciidoc b/docs/dev-tools/searchprofiler/gs-index.asciidoc deleted file mode 100644 index b4f5d48290f5e3..00000000000000 --- a/docs/dev-tools/searchprofiler/gs-index.asciidoc +++ /dev/null @@ -1,20 +0,0 @@ -[role="xpack"] -[[xpack-profiler]] -= Profiling queries and aggregations - -[partintro] --- -{es} has a powerful {ref}/search-profile.html[Profile API] which can be used to inspect and analyze -your search queries. The response returns a large JSON blob, which can be -difficult to analyze manually. - -The {searchprofiler} tool can transform this JSON output -into a visualization that is easy to navigate, allowing you to diagnose and debug -poorly performing queries much faster. - -[role="screenshot"] -image::dev-tools/searchprofiler/images/overview.png["{searchprofiler} Visualization"] - --- - -include::getting-started.asciidoc[] diff --git a/docs/dev-tools/searchprofiler/images/filter.png b/docs/dev-tools/searchprofiler/images/filter.png index a740ec44b9d805..0bcfd7ca5cfad6 100644 Binary files a/docs/dev-tools/searchprofiler/images/filter.png and b/docs/dev-tools/searchprofiler/images/filter.png differ diff --git a/docs/dev-tools/searchprofiler/images/gs10.png b/docs/dev-tools/searchprofiler/images/gs10.png index 6be78b2ce8eb3e..e9a6615f50ac35 100644 Binary files a/docs/dev-tools/searchprofiler/images/gs10.png and b/docs/dev-tools/searchprofiler/images/gs10.png differ diff --git a/docs/dev-tools/searchprofiler/images/gs8.png b/docs/dev-tools/searchprofiler/images/gs8.png index 7ab8389897e4ef..75b93d4dfbdb76 100644 Binary files a/docs/dev-tools/searchprofiler/images/gs8.png and b/docs/dev-tools/searchprofiler/images/gs8.png differ diff --git a/docs/dev-tools/searchprofiler/images/overview.png b/docs/dev-tools/searchprofiler/images/overview.png index 19df1700a5bae1..2669adc13b349a 100644 Binary files a/docs/dev-tools/searchprofiler/images/overview.png and b/docs/dev-tools/searchprofiler/images/overview.png differ diff --git a/docs/dev-tools/searchprofiler/images/pasting.png b/docs/dev-tools/searchprofiler/images/pasting.png deleted file mode 100644 index 466ab9159bfed2..00000000000000 Binary files a/docs/dev-tools/searchprofiler/images/pasting.png and /dev/null differ diff --git a/docs/dev-tools/searchprofiler/images/search-profiler-json.png b/docs/dev-tools/searchprofiler/images/search-profiler-json.png new file mode 100644 index 00000000000000..a81286c9e6cca8 Binary files /dev/null and b/docs/dev-tools/searchprofiler/images/search-profiler-json.png differ diff --git a/docs/dev-tools/searchprofiler/index.asciidoc b/docs/dev-tools/searchprofiler/index.asciidoc index aca96dbfe3ee32..c323427318d549 100644 --- a/docs/dev-tools/searchprofiler/index.asciidoc +++ b/docs/dev-tools/searchprofiler/index.asciidoc @@ -1,20 +1,324 @@ [role="xpack"] [[xpack-profiler]] -== Profiling queries and aggregations +== Profile queries and aggregations -{es} has a powerful {ref}/search-profile.html[Profile API] which can be used to inspect and analyze +{es} has a powerful {ref}/search-profile.html[Profile API] that you can use to inspect and analyze your search queries. The response returns a large JSON blob, which can be difficult to analyze manually. -The {searchprofiler} tool can transform this JSON output +The *{searchprofiler}* tool can transform this JSON output into a visualization that is easy to navigate, allowing you to diagnose and debug poorly performing queries much faster. +[float] +[[search-profiler-getting-started]] +=== Get started -image::dev-tools/searchprofiler/images/overview.png["{searchprofiler} Visualization"] +*{searchprofiler}* is automatically enabled in {kib}. Open the main menu, +click *Dev Tools*, and then click *{searchprofiler}* +to get started. -include::getting-started.asciidoc[] +*{searchprofiler}* displays the names of the indices searched, the shards in each index, +and how long it took for the query to complete. To try it out, replace the default `match_all` query +with the query you want to profile, and then click *Profile*. -include::more-complicated.asciidoc[] +The following example shows the results of profiling the `match_all` query. +If you take a closer look at the information for the `.security_7` sample index, the +*Cumulative time* field shows you that the query took 0.028ms to execute. -include::pasting.asciidoc[] +[role="screenshot"] +image::dev-tools/searchprofiler/images/overview.png["{searchprofiler} visualization"] + + +[NOTE] +==== +The cumulative time metric is the sum of individual shard times. +It is not necessarily the actual time it took for the query to return (wall clock time). +Because shards might be processed in parallel on multiple nodes, the wall clock time can +be significantly less than the cumulative time. However, if shards are colocated on the +same node and executed serially, the wall clock time is closer to the cumulative time. + +While the cumulative time metric is useful for comparing the performance of your +indices and shards, it doesn't necessarily represent the actual physical query times. +==== + +To see more profiling information, click *View details*. You'll +see details about the query components that ran on the shard and the timing +breakdown of low-level methods. For more information, refer to {ref}/search-profile.html#profiling-queries[Profiling queries]. + +[float] +=== Filter for an index or type + +By default, all queries executed by the *{searchprofiler}* are sent +to `GET /_search`. It searches across your entire cluster (all indices, all types). + +To query a specific index or type, you can use the *Index* filter. + +In the following example, the query is executed against the indices `.security-7` and `kibana_sample_data_ecommerce`. +This is equivalent making a request to `GET /test,kibana_1/_search`. + +[role="screenshot"] +image::dev-tools/searchprofiler/images/filter.png["Filtering by index and type"] + +[[profile-complicated-query]] +[float] +=== Profile a more complicated query + +To understand how the query trees are displayed inside the *{searchprofiler}*, +take a look at a more complicated query. + +. Index the following data via *Console*: ++ +-- +[source,js] +-------------------------------------------------- +POST test/_bulk +{"index":{}} +{"name":"aaron","age":23,"hair":"brown"} +{"index":{}} +{"name":"sue","age":19,"hair":"red"} +{"index":{}} +{"name":"sally","age":19,"hair":"blonde"} +{"index":{}} +{"name":"george","age":19,"hair":"blonde"} +{"index":{}} +{"name":"fred","age":69,"hair":"blonde"} +-------------------------------------------------- +// CONSOLE +-- + +. From the *{searchprofiler}*, enter *test* in the *Index* field to restrict profiled +queries to the `test` index. + +. Replace the default `match_all` query in the query editor with a query that has two sub-query +components and includes a simple aggregation: ++ +-- +[source,js] +-------------------------------------------------- +{ + "query": { + "bool": { + "should": [ + { + "match": { + "name": "fred" + } + }, + { + "terms": { + "name": [ + "sue", + "sally" + ] + } + } + ] + } + }, + "aggs": { + "stats": { + "stats": { + "field": "price" + } + } + } +} +-------------------------------------------------- +// NOTCONSOLE +-- + +. Click *Profile* to profile the query and visualize the results. ++ +[role="screenshot"] +image::dev-tools/searchprofiler/images/gs8.png["Profiling the more complicated query"] ++ +- The top `BooleanQuery` component corresponds to the bool in the query. +- The second `BooleanQuery` corresponds to the terms query, which is internally +converted to a `Boolean` of should clauses. It has two child queries that correspond +to "sally" and "sue from the terms query. +- The `TermQuery` that's labeled with "name:fred" corresponds to match: fred in the query. ++ +If you look at the time columns, you can see that *Self time* and *Total time* are no longer +identical on all the rows. *Self time* represents how long the query component took to execute. +*Total time* is the time a query component and all its children took to execute. +Therefore, queries like the Boolean queries often have a larger total time than self time. + +. Click *Aggregation Profile* to view aggregation profiling statistics. ++ +This query includes a `stats` agg on the `"age"` field. +The *Aggregation Profile* tab is only enabled when the query being profiled contains an aggregation. + +. Click *View details* to view the timing breakdown. ++ +[role="screenshot"] +image::dev-tools/searchprofiler/images/gs10.png["Drilling into the first shard's details"] ++ +For more information about how the *{searchprofiler}* works, how timings are calculated, and +how to interpret various results, see +{ref}/search-profile.html#profiling-queries[Profiling queries]. + +[[profiler-render-JSON]] +[float] +=== Render pre-captured profiler JSON + +The *{searchprofiler}* queries the cluster that the {kib} node is attached to. +It does this by executing the query against the cluster and collecting the results. + +Sometimes you might want to investigate performance problems that are temporal in nature. +For example, a query might only be slow at certain time of day when many customers are using your system. +You can set up a process to automatically profile slow queries when they occur and then +save those profile responses for later analysis. + +The *{searchprofiler}* supports this workflow by allowing you to paste the +pre-captured JSON in the query editor. The *{searchprofiler}* will detect that you +have entered a JSON response (rather than a query) and will render just the visualization, +rather than querying the cluster. + +To see how this works, copy and paste the following profile response into the +query editor and click *Profile*. + +[source,js] +-------------------------------------------------- +{ + "took": 3, + "timed_out": false, + "_shards": { + "total": 1, + "successful": 1, + "failed": 0 + }, + "hits": { + "total": 1, + "max_score": 1.3862944, + "hits": [ + { + "_index": "test", + "_type": "test", + "_id": "AVi3aRDmGKWpaS38wV57", + "_score": 1.3862944, + "_source": { + "name": "fred", + "age": 69, + "hair": "blonde" + } + } + ] + }, + "profile": { + "shards": [ + { + "id": "[O-l25nM4QN6Z68UA5rUYqQ][test][0]", + "searches": [ + { + "query": [ + { + "type": "BooleanQuery", + "description": "+name:fred #(ConstantScore(*:*))^0.0", + "time": "0.5884370000ms", + "breakdown": { + "score": 7243, + "build_scorer_count": 1, + "match_count": 0, + "create_weight": 196239, + "next_doc": 9851, + "match": 0, + "create_weight_count": 1, + "next_doc_count": 2, + "score_count": 1, + "build_scorer": 375099, + "advance": 0, + "advance_count": 0 + }, + "children": [ + { + "type": "TermQuery", + "description": "name:fred", + "time": "0.3016880000ms", + "breakdown": { + "score": 4218, + "build_scorer_count": 1, + "match_count": 0, + "create_weight": 132425, + "next_doc": 2196, + "match": 0, + "create_weight_count": 1, + "next_doc_count": 2, + "score_count": 1, + "build_scorer": 162844, + "advance": 0, + "advance_count": 0 + } + }, + { + "type": "BoostQuery", + "description": "(ConstantScore(*:*))^0.0", + "time": "0.1223030000ms", + "breakdown": { + "score": 0, + "build_scorer_count": 1, + "match_count": 0, + "create_weight": 17366, + "next_doc": 0, + "match": 0, + "create_weight_count": 1, + "next_doc_count": 0, + "score_count": 0, + "build_scorer": 102329, + "advance": 2604, + "advance_count": 2 + }, + "children": [ + { + "type": "MatchAllDocsQuery", + "description": "*:*", + "time": "0.03307600000ms", + "breakdown": { + "score": 0, + "build_scorer_count": 1, + "match_count": 0, + "create_weight": 6068, + "next_doc": 0, + "match": 0, + "create_weight_count": 1, + "next_doc_count": 0, + "score_count": 0, + "build_scorer": 25615, + "advance": 1389, + "advance_count": 2 + } + } + ] + } + ] + } + ], + "rewrite_time": 168640, + "collector": [ + { + "name": "CancellableCollector", + "reason": "search_cancelled", + "time": "0.02952900000ms", + "children": [ + { + "name": "SimpleTopScoreDocCollector", + "reason": "search_top_hits", + "time": "0.01931700000ms" + } + ] + } + ] + } + ], + "aggregations": [] + } + ] + } +} +-------------------------------------------------- +// NOTCONSOLE + +Your output should look similar to this: + +[role="screenshot"] +image::dev-tools/searchprofiler/images/search-profiler-json.png["Rendering pre-captured profiler JSON"] diff --git a/docs/dev-tools/searchprofiler/more-complicated.asciidoc b/docs/dev-tools/searchprofiler/more-complicated.asciidoc deleted file mode 100644 index 338341d65924dd..00000000000000 --- a/docs/dev-tools/searchprofiler/more-complicated.asciidoc +++ /dev/null @@ -1,104 +0,0 @@ -[role="xpack"] -[[profiler-complicated]] -=== Profiling a more complicated query - -To understand how the query trees are displayed inside the {searchprofiler}, -let's look at a more complicated query. - -. Index the following data via *Console*: -+ --- -[source,js] --------------------------------------------------- -POST test/_bulk -{"index":{}} -{"name":"aaron","age":23,"hair":"brown"} -{"index":{}} -{"name":"sue","age":19,"hair":"red"} -{"index":{}} -{"name":"sally","age":19,"hair":"blonde"} -{"index":{}} -{"name":"george","age":19,"hair":"blonde"} -{"index":{}} -{"name":"fred","age":69,"hair":"blonde"} --------------------------------------------------- -// CONSOLE --- - -. From the {searchprofiler}, enter "test" in the *Index* field to restrict profiled -queries to the `test` index. - -. Replace the default `match_all` query in the query editor with a query that has two sub-query -components and includes a simple aggregation: -+ --- -[source,js] --------------------------------------------------- -{ - "query": { - "bool": { - "should": [ - { - "match": { - "name": "fred" - } - }, - { - "terms": { - "name": [ - "sue", - "sally" - ] - } - } - ] - } - }, - "aggs": { - "stats": { - "stats": { - "field": "price" - } - } - } -} --------------------------------------------------- -// NOTCONSOLE --- - -. Click *Profile* to profile the query and visualize the results. -. Select the shard to view the query details. -+ -[role="screenshot"] -image::dev-tools/searchprofiler/images/gs8.png["Profiling the more complicated query"] - - -The detail view contains a row for each query component: - - - The top-level `BooleanQuery` component corresponds to the bool in the query. - - The second `BooleanQuery` corresponds to the terms query, which is internally - converted to a `Boolean` of should clauses. It has two child queries that correspond - to "sue" and "sally" from the terms query. - - The `TermQuery` that's labeled with "name:fred" corresponds to match: fred in the query. - -If you look at the time columns, you can see that "Self time" and "Total time" are no longer -identical on all the rows. Self time represents how long the query component took to execute. -Total time is the time a query component and all its children took to execute. -Therefore, queries like the Boolean queries often have a larger total time than self time. - - -==== Aggregations - -This particular query also includes a aggregation (a `stats` agg on the `"age"` field). -Click *Aggregation Profile* to view aggregation profiling statistics (this tab -is only enabled if the query being profiled contains an aggregation). - - -Select the name of the shard to view the aggregation details and timing breakdown. - -[role="screenshot"] -image::dev-tools/searchprofiler/images/gs10.png["Drilling into the first shard's details"] - -For more information about how the {searchprofiler} works, how timings are calculated, and -how to interpret various results, see -{ref}/search-profile.html#profiling-queries[Profiling queries]. diff --git a/docs/dev-tools/searchprofiler/pasting.asciidoc b/docs/dev-tools/searchprofiler/pasting.asciidoc deleted file mode 100644 index 9257a4d84fb562..00000000000000 --- a/docs/dev-tools/searchprofiler/pasting.asciidoc +++ /dev/null @@ -1,161 +0,0 @@ -[role="xpack"] -[[profiler-render]] -=== Rendering pre-captured profiler JSON - -The {searchprofiler} queries the cluster that the Kibana node is attached to. -It does this by executing the query against the cluster and collecting the results. - -But sometimes you may want to investigate performance problems that are temporal in nature. -For example, a query might only be slow at certain time of day when many customers are using your system. -You can setup a process to automatically profile slow queries when they occur and then -save those profile responses for later analysis. - -The {searchprofiler} supports this workflow by allowing you to paste the -pre-captured JSON in the query editor. The {searchprofiler} will detect that you -have entered a JSON response (rather than a query) and will just render the visualization, -rather than querying the cluster. - -To see how this works, copy and paste the following profile response into the -query editor and click *Profile*. - -[source,js] --------------------------------------------------- -{ - "took": 3, - "timed_out": false, - "_shards": { - "total": 1, - "successful": 1, - "failed": 0 - }, - "hits": { - "total": 1, - "max_score": 1.3862944, - "hits": [ - { - "_index": "test", - "_type": "test", - "_id": "AVi3aRDmGKWpaS38wV57", - "_score": 1.3862944, - "_source": { - "name": "fred", - "age": 69, - "hair": "blonde" - } - } - ] - }, - "profile": { - "shards": [ - { - "id": "[O-l25nM4QN6Z68UA5rUYqQ][test][0]", - "searches": [ - { - "query": [ - { - "type": "BooleanQuery", - "description": "+name:fred #(ConstantScore(*:*))^0.0", - "time": "0.5884370000ms", - "breakdown": { - "score": 7243, - "build_scorer_count": 1, - "match_count": 0, - "create_weight": 196239, - "next_doc": 9851, - "match": 0, - "create_weight_count": 1, - "next_doc_count": 2, - "score_count": 1, - "build_scorer": 375099, - "advance": 0, - "advance_count": 0 - }, - "children": [ - { - "type": "TermQuery", - "description": "name:fred", - "time": "0.3016880000ms", - "breakdown": { - "score": 4218, - "build_scorer_count": 1, - "match_count": 0, - "create_weight": 132425, - "next_doc": 2196, - "match": 0, - "create_weight_count": 1, - "next_doc_count": 2, - "score_count": 1, - "build_scorer": 162844, - "advance": 0, - "advance_count": 0 - } - }, - { - "type": "BoostQuery", - "description": "(ConstantScore(*:*))^0.0", - "time": "0.1223030000ms", - "breakdown": { - "score": 0, - "build_scorer_count": 1, - "match_count": 0, - "create_weight": 17366, - "next_doc": 0, - "match": 0, - "create_weight_count": 1, - "next_doc_count": 0, - "score_count": 0, - "build_scorer": 102329, - "advance": 2604, - "advance_count": 2 - }, - "children": [ - { - "type": "MatchAllDocsQuery", - "description": "*:*", - "time": "0.03307600000ms", - "breakdown": { - "score": 0, - "build_scorer_count": 1, - "match_count": 0, - "create_weight": 6068, - "next_doc": 0, - "match": 0, - "create_weight_count": 1, - "next_doc_count": 0, - "score_count": 0, - "build_scorer": 25615, - "advance": 1389, - "advance_count": 2 - } - } - ] - } - ] - } - ], - "rewrite_time": 168640, - "collector": [ - { - "name": "CancellableCollector", - "reason": "search_cancelled", - "time": "0.02952900000ms", - "children": [ - { - "name": "SimpleTopScoreDocCollector", - "reason": "search_top_hits", - "time": "0.01931700000ms" - } - ] - } - ] - } - ], - "aggregations": [] - } - ] - } -} --------------------------------------------------- -// NOTCONSOLE - -image::dev-tools/searchprofiler/images/pasting.png["Visualizing pre-collected responses"] diff --git a/docs/redirects.asciidoc b/docs/redirects.asciidoc index 31d970cec0e23c..8934e29a6adadd 100644 --- a/docs/redirects.asciidoc +++ b/docs/redirects.asciidoc @@ -337,4 +337,21 @@ This content has moved. Refer to <> and <>. \ No newline at end of file +This content has moved. Refer to <>. + +[role="exclude",id="profiler-getting-started"] +== Getting start with Search Profiler + +This content has moved. Refer to <>. + + +[role="exclude",id="profiler-complicated"] +== Profiling a more complicated querying + +This content has moved. Refer to <>. + + +[role="exclude",id="profiler-render"] +== Rendering pre-captured profiler JSON + +This content has moved. Refer to <>.