OpenSearch/docs/reference/cat/indices.asciidoc

126 lines
4.2 KiB
Plaintext
Raw Normal View History

2013-11-14 20:14:39 -05:00
[[cat-indices]]
== cat indices
2013-11-14 20:14:39 -05:00
The `indices` command provides a cross-section of each index. This
information *spans nodes*. For example:
2013-11-14 20:14:39 -05:00
[source,js]
2013-11-14 20:14:39 -05:00
--------------------------------------------------
GET /_cat/indices/twi*?v&s=index
2013-11-14 20:14:39 -05:00
--------------------------------------------------
// CONSOLE
// TEST[setup:huge_twitter]
// TEST[s/^/PUT twitter2\n{"settings": {"number_of_replicas": 0}}\n/]
Might respond with:
[source,txt]
--------------------------------------------------
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open twitter u8FNjxh8Rfy_awN11oDKYQ 1 1 1200 0 88.1kb 88.1kb
green open twitter2 nYFWZEO7TUiOjLQXBaYJpA 5 0 0 0 260b 260b
--------------------------------------------------
// TESTRESPONSE[s/\d+(\.\d+)?[tgmk]?b/\\d+(\\.\\d+)?[tgmk]?b/]
// TESTRESPONSE[s/u8FNjxh8Rfy_awN11oDKYQ|nYFWZEO7TUiOjLQXBaYJpA/.+/ _cat]
2013-11-14 20:14:39 -05:00
We can tell quickly how many shards make up an index, the number of
docs, deleted docs, primary store size, and total store size (all shards including replicas).
All these exposed metrics come directly from Lucene APIs.
2013-11-14 20:14:39 -05:00
*Notes:*
1. As the number of documents and deleted documents shown in this are at the lucene level,
it includes all the hidden documents (e.g. from nested documents) as well.
2. To get actual count of documents at the Elasticsearch level, the recommended way
is to use either the <<cat-count>> or the <<search-count>>
[float]
[[pri-flag]]
=== Primaries
The index stats by default will show them for all of an index's
shards, including replicas. A `pri` flag can be supplied to enable
the view of relevant stats in the context of only the primaries.
2013-11-14 20:14:39 -05:00
[float]
[[examples]]
=== Examples
Which indices are yellow?
[source,js]
--------------------------------------------------
GET /_cat/indices?v&health=yellow
--------------------------------------------------
// CONSOLE
// TEST[continued]
Which looks like:
[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 twitter u8FNjxh8Rfy_awN11oDKYQ 1 1 1200 0 88.1kb 88.1kb
2013-11-14 20:14:39 -05:00
--------------------------------------------------
// TESTRESPONSE[s/\d+(\.\d+)?[tgmk]?b/\\d+(\\.\\d+)?[tgmk]?b/]
// TESTRESPONSE[s/u8FNjxh8Rfy_awN11oDKYQ/.+/ _cat]
2013-11-14 20:14:39 -05:00
Which index has the largest number of documents?
2013-11-14 20:14:39 -05:00
[source,js]
--------------------------------------------------
GET /_cat/indices?v&s=docs.count:desc
--------------------------------------------------
// CONSOLE
// TEST[continued]
Which looks like:
[source,txt]
--------------------------------------------------
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open twitter u8FNjxh8Rfy_awN11oDKYQ 1 1 1200 0 88.1kb 88.1kb
green open twitter2 nYFWZEO7TUiOjLQXBaYJpA 5 0 0 0 260b 260b
--------------------------------------------------
// TESTRESPONSE[s/\d+(\.\d+)?[tgmk]?b/\\d+(\\.\\d+)?[tgmk]?b/]
// TESTRESPONSE[s/u8FNjxh8Rfy_awN11oDKYQ|nYFWZEO7TUiOjLQXBaYJpA/.+/ _cat]
How many merge operations have the shards for the `twitter` completed?
[source,js]
2013-11-14 20:14:39 -05:00
--------------------------------------------------
GET /_cat/indices/twitter?pri&v&h=health,index,pri,rep,docs.count,mt
--------------------------------------------------
// CONSOLE
// TEST[continued]
Might look like:
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]
--------------------------------------------------
health index pri rep docs.count mt pri.mt
yellow twitter 1 1 1200 16 16
2013-11-14 20:14:39 -05:00
--------------------------------------------------
// TESTRESPONSE[s/16/\\d+/ _cat]
How much memory is used per index?
[source,js]
--------------------------------------------------
GET /_cat/indices?v&h=i,tm&s=tm:desc
--------------------------------------------------
// CONSOLE
// TEST[continued]
Might look like:
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]
--------------------------------------------------
i tm
twitter 8.1gb
twitter2 30.5kb
--------------------------------------------------
// TESTRESPONSE[s/\d+(\.\d+)?[tgmk]?b/\\d+(\\.\\d+)?[tgmk]?b/]
// TESTRESPONSE[_cat]