Getting Startededit

The Query Profiler is automatically enabled in Kibana. Go to Dev Tools > Search Profiler to get started.

Query Profiler 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 0.067ms to execute.

Query Profiler 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 Profiling queries.

Index and type filteringedit

By default, all queries executed by the Query Profiler 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 at the top left.

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.

Filtering by index and type