OpenSearch/docs/reference/cat.asciidoc

245 lines
6.6 KiB
Plaintext
Raw Normal View History

2013-11-14 20:14:39 -05:00
[[cat]]
= cat APIs
["float",id="intro"]
== Introduction
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 API
aims to meet this need.
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.
2013-11-14 20:14:39 -05:00
[float]
[[common-parameters]]
== Common parameters
[float]
[[verbose]]
=== Verbose
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,js]
--------------------------------------------------
GET /_cat/master?v
--------------------------------------------------
// CONSOLE
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
[float]
[[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,js]
--------------------------------------------------
GET /_cat/master?help
--------------------------------------------------
// CONSOLE
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/twitter?help` or `GET _cat/indices/twi*?help`
results in an error. Use `GET _cat/shards?help` or `GET _cat/indices?help`
instead.
[float]
[[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,js]
--------------------------------------------------
GET /_cat/nodes?h=ip,port,heapPercent,name
--------------------------------------------------
// CONSOLE
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`.
2013-11-14 20:14:39 -05:00
[float]
[[numeric-formats]]
=== Numeric formats
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. We only need to tweak two things. First, we want to turn
off human mode. We'll use a byte-level resolution. Then we'll pipe
our output into `sort` using the appropriate column, which in this
case is the eighth one.
2013-11-14 20:14:39 -05:00
[source,sh]
2013-11-14 20:14:39 -05:00
--------------------------------------------------
% curl '192.168.56.10:9200/_cat/indices?bytes=b' | sort -rnk8
green wiki2 3 0 10000 0 105274918 105274918
green wiki1 3 0 10000 413 103776272 103776272
green foo 1 0 227 0 2065131 2065131
--------------------------------------------------
// NOTCONSOLE
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.
2016-02-05 08:47:27 -05:00
[float]
=== 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": "twitter",
"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": "twitter",
"pri": "5",
"rep": "1",
"docs.count": "0",
"docs.deleted": "0",
"store.size": "650b"
}
]
--------------------------------------------------
// NOTCONSOLE
[float]
[[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/count.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[]
include::cat/thread_pool.asciidoc[]
2013-11-14 20:14:39 -05:00
include::cat/shards.asciidoc[]
include::cat/segments.asciidoc[]
include::cat/snapshots.asciidoc[]
include::cat/templates.asciidoc[]