109 lines
3.3 KiB
Plaintext
109 lines
3.3 KiB
Plaintext
[[cluster-state]]
|
|
=== Cluster State
|
|
|
|
The cluster state API allows access to metadata representing the state of the
|
|
whole cluster. This includes information such as
|
|
|
|
* the set of nodes in the cluster
|
|
|
|
* all cluster-level settings
|
|
|
|
* information about the indices in the cluster, including their mappings and
|
|
settings
|
|
|
|
* the locations of all the shards in the cluster
|
|
|
|
The response is an internal representation of the cluster state and its format
|
|
may change from version to version. If possible, you should obtain any
|
|
information from the cluster state using the other, more stable,
|
|
<<cluster,cluster APIs>>.
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_cluster/state
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
|
|
The response provides the cluster state itself, which can be filtered to only
|
|
retrieve the parts of interest as described below.
|
|
|
|
The cluster's `cluster_uuid` is also returned as part of the top-level response,
|
|
in addition to the `metadata` section. added[6.4.0]
|
|
|
|
NOTE: While the cluster is still forming, it is possible for the `cluster_uuid`
|
|
to be `_na_` as well as the cluster state's version to be `-1`.
|
|
|
|
By default, the cluster state request is routed to the master node, to ensure
|
|
that the latest cluster state is returned. For debugging purposes, you can
|
|
retrieve the cluster state local to a particular node by adding `local=true` to
|
|
the query string.
|
|
|
|
[float]
|
|
==== Response Filters
|
|
|
|
The cluster state contains information about all the indices in the cluster,
|
|
including their mappings, as well as templates and other metadata. This means it
|
|
can sometimes be quite large. To avoid the need to process all this information
|
|
you can request only the part of the cluster state that you need:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_cluster/state/{metrics}
|
|
GET /_cluster/state/{metrics}/{indices}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
|
|
`{metrics}` is a comma-separated list of the following options.
|
|
|
|
`version`::
|
|
Shows the cluster state version.
|
|
|
|
`master_node`::
|
|
Shows the elected `master_node` part of the response
|
|
|
|
`nodes`::
|
|
Shows the `nodes` part of the response
|
|
|
|
`routing_table`::
|
|
Shows the `routing_table` part of the response. If you supply a comma
|
|
separated list of indices, the returned output will only contain the routing
|
|
table for these indices.
|
|
|
|
`metadata`::
|
|
Shows the `metadata` part of the response. If you supply a comma separated
|
|
list of indices, the returned output will only contain metadata for these
|
|
indices.
|
|
|
|
`blocks`::
|
|
Shows the `blocks` part of the response.
|
|
|
|
`_all`::
|
|
Shows all metrics.
|
|
|
|
The following example returns only `metadata` and `routing_table` data for the
|
|
`foo` and `bar` indices:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_cluster/state/metadata,routing_table/foo,bar
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
|
|
The next example returns everything for the `foo` and `bar` indices:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_cluster/state/_all/foo,bar
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
|
|
Finally, this example return only the `blocks` metadata:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_cluster/state/blocks
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
|
|
|