OpenSearch/docs/reference/cat.asciidoc

274 lines
7.8 KiB
Plaintext
Raw Normal View History

2013-11-14 20:14:39 -05:00
[[cat]]
== cat APIs
2013-11-14 20:14:39 -05:00
["float",id="intro"]
=== Introduction
2013-11-14 20:14:39 -05:00
JSON is great... for computers. Even if it's pretty-printed, trying
to find relationships in the data is tedious. Human eyes, especially
when looking at a terminal, need compact and aligned text. The cat APIs
aim to meet this need.
[IMPORTANT]
====
cat APIs are only intended for human consumption using the
{kibana-ref}/console-kibana.html[Kibana console] or command line. They are _not_
intended for use by applications. For application consumption, we recommend
using a corresponding JSON API.
====
2013-11-14 20:14:39 -05:00
2014-01-06 12:23:24 -05:00
All the cat commands accept a query string parameter `help` to see all
the headers and info they provide, and the `/_cat` command alone lists all
the available commands.
[discrete]
2013-11-14 20:14:39 -05:00
[[common-parameters]]
=== Common parameters
2013-11-14 20:14:39 -05:00
[discrete]
2013-11-14 20:14:39 -05:00
[[verbose]]
==== Verbose
2013-11-14 20:14:39 -05:00
Each of the commands accepts a query string parameter `v` to turn on
verbose output. For example:
2013-11-14 20:14:39 -05:00
[source,console]
--------------------------------------------------
GET /_cat/master?v
--------------------------------------------------
Might respond with:
Enforce that responses in docs are valid json (#26249) All of the snippets in our docs marked with `// TESTRESPONSE` are checked against the response from Elasticsearch but, due to the way they are implemented they are actually parsed as YAML instead of JSON. Luckilly, all valid JSON is valid YAML! Unfurtunately that means that invalid JSON has snuck into the exmples! This adds a step during the build to parse them as JSON and fail the build if they don't parse. But no! It isn't quite that simple. The displayed text of some of these responses looks like: ``` { ... "aggregations": { "range": { "buckets": [ { "to": 1.4436576E12, "to_as_string": "10-2015", "doc_count": 7, "key": "*-10-2015" }, { "from": 1.4436576E12, "from_as_string": "10-2015", "doc_count": 0, "key": "10-2015-*" } ] } } } ``` Note the `...` which isn't valid json but we like it anyway and want it in the output. We use substitution rules to convert the `...` into the response we expect. That yields a response that looks like: ``` { "took": $body.took,"timed_out": false,"_shards": $body._shards,"hits": $body.hits, "aggregations": { "range": { "buckets": [ { "to": 1.4436576E12, "to_as_string": "10-2015", "doc_count": 7, "key": "*-10-2015" }, { "from": 1.4436576E12, "from_as_string": "10-2015", "doc_count": 0, "key": "10-2015-*" } ] } } } ``` That is what the tests consume but it isn't valid JSON! Oh no! We don't want to go update all the substitution rules because that'd be huge and, ultimately, wouldn't buy much. So we quote the `$body.took` bits before parsing the JSON. Note the responses that we use for the `_cat` APIs are all converted into regexes and there is no expectation that they are valid JSON. Closes #26233
2017-08-17 09:02:10 -04:00
[source,txt]
2013-11-14 20:14:39 -05:00
--------------------------------------------------
id host ip node
u_n93zwxThWHi1PDBJAGAg 127.0.0.1 127.0.0.1 u_n93zw
2013-11-14 20:14:39 -05:00
--------------------------------------------------
// TESTRESPONSE[s/u_n93zw(xThWHi1PDBJAGAg)?/.+/ non_json]
2013-11-14 20:14:39 -05:00
[discrete]
[[help]]
==== Help
2014-01-06 12:23:24 -05:00
Each of the commands accepts a query string parameter `help` which will
output its available columns. For example:
[source,console]
--------------------------------------------------
GET /_cat/master?help
--------------------------------------------------
Might respond with:
Enforce that responses in docs are valid json (#26249) All of the snippets in our docs marked with `// TESTRESPONSE` are checked against the response from Elasticsearch but, due to the way they are implemented they are actually parsed as YAML instead of JSON. Luckilly, all valid JSON is valid YAML! Unfurtunately that means that invalid JSON has snuck into the exmples! This adds a step during the build to parse them as JSON and fail the build if they don't parse. But no! It isn't quite that simple. The displayed text of some of these responses looks like: ``` { ... "aggregations": { "range": { "buckets": [ { "to": 1.4436576E12, "to_as_string": "10-2015", "doc_count": 7, "key": "*-10-2015" }, { "from": 1.4436576E12, "from_as_string": "10-2015", "doc_count": 0, "key": "10-2015-*" } ] } } } ``` Note the `...` which isn't valid json but we like it anyway and want it in the output. We use substitution rules to convert the `...` into the response we expect. That yields a response that looks like: ``` { "took": $body.took,"timed_out": false,"_shards": $body._shards,"hits": $body.hits, "aggregations": { "range": { "buckets": [ { "to": 1.4436576E12, "to_as_string": "10-2015", "doc_count": 7, "key": "*-10-2015" }, { "from": 1.4436576E12, "from_as_string": "10-2015", "doc_count": 0, "key": "10-2015-*" } ] } } } ``` That is what the tests consume but it isn't valid JSON! Oh no! We don't want to go update all the substitution rules because that'd be huge and, ultimately, wouldn't buy much. So we quote the `$body.took` bits before parsing the JSON. Note the responses that we use for the `_cat` APIs are all converted into regexes and there is no expectation that they are valid JSON. Closes #26233
2017-08-17 09:02:10 -04:00
[source,txt]
--------------------------------------------------
id | | node id
host | h | host name
ip | | ip address
node | n | node name
--------------------------------------------------
// TESTRESPONSE[s/[|]/[|]/ non_json]
NOTE: `help` is not supported if any optional url parameter is used.
For example `GET _cat/shards/my-index-000001?help` or `GET _cat/indices/my-index-*?help`
results in an error. Use `GET _cat/shards?help` or `GET _cat/indices?help`
instead.
[discrete]
[[headers]]
==== Headers
2014-01-06 12:23:24 -05:00
Each of the commands accepts a query string parameter `h` which forces
only those columns to appear. For example:
[source,console]
--------------------------------------------------
GET /_cat/nodes?h=ip,port,heapPercent,name
--------------------------------------------------
Responds with:
Enforce that responses in docs are valid json (#26249) All of the snippets in our docs marked with `// TESTRESPONSE` are checked against the response from Elasticsearch but, due to the way they are implemented they are actually parsed as YAML instead of JSON. Luckilly, all valid JSON is valid YAML! Unfurtunately that means that invalid JSON has snuck into the exmples! This adds a step during the build to parse them as JSON and fail the build if they don't parse. But no! It isn't quite that simple. The displayed text of some of these responses looks like: ``` { ... "aggregations": { "range": { "buckets": [ { "to": 1.4436576E12, "to_as_string": "10-2015", "doc_count": 7, "key": "*-10-2015" }, { "from": 1.4436576E12, "from_as_string": "10-2015", "doc_count": 0, "key": "10-2015-*" } ] } } } ``` Note the `...` which isn't valid json but we like it anyway and want it in the output. We use substitution rules to convert the `...` into the response we expect. That yields a response that looks like: ``` { "took": $body.took,"timed_out": false,"_shards": $body._shards,"hits": $body.hits, "aggregations": { "range": { "buckets": [ { "to": 1.4436576E12, "to_as_string": "10-2015", "doc_count": 7, "key": "*-10-2015" }, { "from": 1.4436576E12, "from_as_string": "10-2015", "doc_count": 0, "key": "10-2015-*" } ] } } } ``` That is what the tests consume but it isn't valid JSON! Oh no! We don't want to go update all the substitution rules because that'd be huge and, ultimately, wouldn't buy much. So we quote the `$body.took` bits before parsing the JSON. Note the responses that we use for the `_cat` APIs are all converted into regexes and there is no expectation that they are valid JSON. Closes #26233
2017-08-17 09:02:10 -04:00
[source,txt]
--------------------------------------------------
127.0.0.1 9300 27 sLBaIGK
--------------------------------------------------
// TESTRESPONSE[s/9300 27 sLBaIGK/\\d+ \\d+ .+/ non_json]
You can also request multiple columns using simple wildcards like
`/_cat/thread_pool?h=ip,queue*` to get all headers (or aliases) starting
with `queue`.
[discrete]
2013-11-14 20:14:39 -05:00
[[numeric-formats]]
==== Numeric formats
2013-11-14 20:14:39 -05:00
Many commands provide a few types of numeric output, either a byte, size
or a time value. By default, these types are human-formatted,
2013-11-14 20:14:39 -05:00
for example, `3.5mb` instead of `3763212`. The human values are not
sortable numerically, so in order to operate on these values where
order is important, you can change it.
Say you want to find the largest index in your cluster (storage used
by all the shards, not number of documents). The `/_cat/indices` API
is ideal. You only need to add three things to the API request:
2013-11-14 20:14:39 -05:00
. The `bytes` query string parameter with a value of `b` to get byte-level resolution.
. The `s` (sort) parameter with a value of `store.size:desc` to sort the output
by shard storage in descending order.
. The `v` (verbose) parameter to include column headings in the response.
[source,console]
--------------------------------------------------
GET /_cat/indices?bytes=b&s=store.size:desc&v
--------------------------------------------------
// TEST[setup:my_index_huge]
// TEST[s/^/PUT my-index-000002\n{"settings": {"number_of_replicas": 0}}\n/]
The API returns the following response:
[source,txt]
2013-11-14 20:14:39 -05:00
--------------------------------------------------
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open my-index-000001 u8FNjxh8Rfy_awN11oDKYQ 1 1 1200 0 72171 72171
green open my-index-000002 nYFWZEO7TUiOjLQXBaYJpA 1 0 0 0 230 230
2013-11-14 20:14:39 -05:00
--------------------------------------------------
// TESTRESPONSE[s/72171|230/\\d+/]
// TESTRESPONSE[s/u8FNjxh8Rfy_awN11oDKYQ|nYFWZEO7TUiOjLQXBaYJpA/.+/ non_json]
2020-08-06 04:40:55 -04:00
// TESTRESPONSE[skip:"AwaitsFix https://github.com/elastic/elasticsearch/issues/51619"]
2013-11-14 20:14:39 -05:00
If you want to change the <<time-units,time units>>, use `time` parameter.
If you want to change the <<size-units,size units>>, use `size` parameter.
If you want to change the <<byte-units,byte units>>, use `bytes` parameter.
[discrete]
==== Response as text, json, smile, yaml or cbor
[source,sh]
--------------------------------------------------
% curl 'localhost:9200/_cat/indices?format=json&pretty'
[
{
"pri.store.size": "650b",
"health": "yellow",
"status": "open",
"index": "my-index-000001",
"pri": "5",
"rep": "1",
"docs.count": "0",
"docs.deleted": "0",
"store.size": "650b"
}
]
--------------------------------------------------
// NOTCONSOLE
2016-02-05 08:47:27 -05:00
Currently supported formats (for the `?format=` parameter):
- text (default)
- json
- smile
- yaml
- cbor
2016-02-05 08:47:27 -05:00
Alternatively you can set the "Accept" HTTP header to the appropriate media format.
All formats above are supported, the GET parameter takes precedence over the header.
2016-02-05 08:47:27 -05:00
For example:
[source,sh]
--------------------------------------------------
% curl '192.168.56.10:9200/_cat/indices?pretty' -H "Accept: application/json"
[
{
"pri.store.size": "650b",
"health": "yellow",
"status": "open",
"index": "my-index-000001",
"pri": "5",
"rep": "1",
"docs.count": "0",
"docs.deleted": "0",
"store.size": "650b"
}
]
--------------------------------------------------
// NOTCONSOLE
[discrete]
[[sort]]
==== Sort
Each of the commands accepts a query string parameter `s` which sorts the table by
the columns specified as the parameter value. Columns are specified either by name or by
alias, and are provided as a comma separated string. By default, sorting is done in
ascending fashion. Appending `:desc` to a column will invert the ordering for
that column. `:asc` is also accepted but exhibits the same behavior as the default sort order.
For example, with a sort string `s=column1,column2:desc,column3`, the table will be
sorted in ascending order by column1, in descending order by column2, and in ascending
order by column3.
[source,sh]
--------------------------------------------------
GET _cat/templates?v&s=order:desc,index_patterns
--------------------------------------------------
//CONSOLE
returns:
Enforce that responses in docs are valid json (#26249) All of the snippets in our docs marked with `// TESTRESPONSE` are checked against the response from Elasticsearch but, due to the way they are implemented they are actually parsed as YAML instead of JSON. Luckilly, all valid JSON is valid YAML! Unfurtunately that means that invalid JSON has snuck into the exmples! This adds a step during the build to parse them as JSON and fail the build if they don't parse. But no! It isn't quite that simple. The displayed text of some of these responses looks like: ``` { ... "aggregations": { "range": { "buckets": [ { "to": 1.4436576E12, "to_as_string": "10-2015", "doc_count": 7, "key": "*-10-2015" }, { "from": 1.4436576E12, "from_as_string": "10-2015", "doc_count": 0, "key": "10-2015-*" } ] } } } ``` Note the `...` which isn't valid json but we like it anyway and want it in the output. We use substitution rules to convert the `...` into the response we expect. That yields a response that looks like: ``` { "took": $body.took,"timed_out": false,"_shards": $body._shards,"hits": $body.hits, "aggregations": { "range": { "buckets": [ { "to": 1.4436576E12, "to_as_string": "10-2015", "doc_count": 7, "key": "*-10-2015" }, { "from": 1.4436576E12, "from_as_string": "10-2015", "doc_count": 0, "key": "10-2015-*" } ] } } } ``` That is what the tests consume but it isn't valid JSON! Oh no! We don't want to go update all the substitution rules because that'd be huge and, ultimately, wouldn't buy much. So we quote the `$body.took` bits before parsing the JSON. Note the responses that we use for the `_cat` APIs are all converted into regexes and there is no expectation that they are valid JSON. Closes #26233
2017-08-17 09:02:10 -04:00
[source,txt]
--------------------------------------------------
name index_patterns order version
pizza_pepperoni [*pepperoni*] 2
sushi_california_roll [*avocado*] 1 1
pizza_hawaiian [*pineapples*] 1
--------------------------------------------------
include::cat/alias.asciidoc[]
2013-11-14 20:14:39 -05:00
include::cat/allocation.asciidoc[]
include::cat/anomaly-detectors.asciidoc[]
2013-11-14 20:14:39 -05:00
include::cat/count.asciidoc[]
include::cat/dataframeanalytics.asciidoc[]
2020-02-26 12:20:36 -05:00
include::cat/datafeeds.asciidoc[]
2014-06-03 05:05:26 -04:00
include::cat/fielddata.asciidoc[]
2013-11-14 20:14:39 -05:00
include::cat/health.asciidoc[]
include::cat/indices.asciidoc[]
include::cat/master.asciidoc[]
include::cat/nodeattrs.asciidoc[]
2013-11-14 20:14:39 -05:00
include::cat/nodes.asciidoc[]
2013-11-29 02:08:54 -05:00
include::cat/pending_tasks.asciidoc[]
2014-06-03 05:05:26 -04:00
include::cat/plugins.asciidoc[]
2013-11-14 20:14:39 -05:00
include::cat/recovery.asciidoc[]
include::cat/repositories.asciidoc[]
2013-11-14 20:14:39 -05:00
include::cat/shards.asciidoc[]
include::cat/segments.asciidoc[]
include::cat/snapshots.asciidoc[]
include::cat/tasks.asciidoc[]
include::cat/templates.asciidoc[]
include::cat/thread_pool.asciidoc[]
include::cat/trainedmodel.asciidoc[]
include::cat/transforms.asciidoc[]