Skip to content

[DOCS] Reformats cluster health and cluster state APIs #45206

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
szabosteve merged 8 commits into from
Aug 8, 2019
Merged

[DOCS] Reformats cluster health and cluster state APIs #45206

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
6f1c541
[DOCS] Reformats cluster health and cluster state APIs.
szabosteve Aug 5, 2019
498a678
Update docs/reference/cluster/health.asciidoc
szabosteve Aug 6, 2019
b4d2b2a
Update docs/reference/cluster/health.asciidoc
szabosteve Aug 6, 2019
20d3683
[DOCS] Addresses feedback.
szabosteve Aug 6, 2019
1b80689
[DOCS] Adds indicators and query params.
szabosteve Aug 7, 2019
674ebce
[DOCS] Changes a query param description to a common param reference.
szabosteve Aug 7, 2019
fd55d0b
Merge branch 'master' into api.reformat
elasticmachine Aug 7, 2019
d1a13e8
Update docs/reference/cluster/health.asciidoc
szabosteve Aug 8, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
130 changes: 59 additions & 71 deletions docs/reference/cluster/health.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,18 +1,44 @@
[[cluster-health]]
=== Cluster Health

The cluster health API allows to get a very simple status on the health
of the cluster. For example, on a quiet single node cluster with a single index
with one shard and one replica, this:
[[cluster-health-api-request]]
==== {api-request-title}

`GET _cluster/health` +

`GET /_cluster/health/test1,test2`

[[cluster-health-api-desc]]
==== {api-description-title}

The cluster health API allows to get a simple status on the health of the
cluster. The API can also be executed against one or more indices to get just
the specified indices health.

The cluster health status is: `green`, `yellow` or `red`. On the shard level, a
`red` status indicates that the specific shard is not allocated in the cluster,
`yellow` means that the primary shard is allocated but replicas are not, and
`green` means that all shards are allocated. The index level status is
controlled by the worst shard status. The cluster status is controlled by the
worst index status.

One of the main benefits of the API is the ability to wait until the cluster
reaches a certain high water-mark health level. For example, the following will
wait for 50 seconds for the cluster to reach the `yellow` level (if it reaches
the `green` or `yellow` status before 50 seconds elapse, it will return at that
point):

[source,js]
--------------------------------------------------
GET _cluster/health
GET /_cluster/health?wait_for_status=yellow&timeout=50s
--------------------------------------------------
// CONSOLE
// TEST[s/^/PUT test1\n/]

Returns this:
[[cluster-health-api-response-body]]
==== {api-response-body-title}

The API returns the following response in case of a quiet single node cluster
with a single index with one shard and one replica:

[source,js]
--------------------------------------------------
Expand All @@ -38,89 +64,51 @@ Returns this:
// TESTRESPONSE[s/"number_of_pending_tasks" : 0,/"number_of_pending_tasks" : $body.number_of_pending_tasks,/]
// TESTRESPONSE[s/"task_max_waiting_in_queue_millis": 0/"task_max_waiting_in_queue_millis": $body.task_max_waiting_in_queue_millis/]

[[cluster-health-api-query-params]]
==== {api-query-parms-title}

The API can also be executed against one or more indices to get just the
specified indices health:

[source,js]
--------------------------------------------------
GET /_cluster/health/test1,test2
--------------------------------------------------
// CONSOLE
// TEST[s/^/PUT test1\nPUT test2\n/]

The cluster health status is: `green`, `yellow` or `red`. On the shard
level, a `red` status indicates that the specific shard is not allocated
in the cluster, `yellow` means that the primary shard is allocated but
replicas are not, and `green` means that all shards are allocated. The
index level status is controlled by the worst shard status. The cluster
status is controlled by the worst index status.

One of the main benefits of the API is the ability to wait until the
cluster reaches a certain high water-mark health level. For example, the
following will wait for 50 seconds for the cluster to reach the `yellow`
level (if it reaches the `green` or `yellow` status before 50 seconds elapse,
it will return at that point):

[source,js]
--------------------------------------------------
GET /_cluster/health?wait_for_status=yellow&timeout=50s
--------------------------------------------------
// CONSOLE

[float]
[[request-params]]
==== Request Parameters

The cluster health API accepts the following request parameters:
The cluster health API accepts the following query parameters:

`level`::
Can be one of `cluster`, `indices` or `shards`. Controls the
details level of the health information returned. Defaults to `cluster`.

`wait_for_status`::
One of `green`, `yellow` or `red`. Will wait (until
the timeout provided) until the status of the cluster changes to the one
provided or better, i.e. `green` > `yellow` > `red`. By default, will not
wait for any status.
(Optional, string) Can be one of `cluster`, `indices` or `shards`. Controls
the details level of the health information returned. Defaults to `cluster`.

include::{docdir}/rest-api/common-parms.asciidoc[tag=local]

include::{docdir}/rest-api/common-parms.asciidoc[tag=timeoutparms]

`wait_for_no_relocating_shards`::
A boolean value which controls whether to wait (until the timeout provided)
for the cluster to have no shard relocations. Defaults to false, which means
it will not wait for relocating shards.
`wait_for_active_shards`::
A number controlling to how many active shards to wait for, `all` to wait
for all shards in the cluster to be active, or `0` to not wait. Defaults to `0`.

`wait_for_events`::
Can be one of `immediate`, `urgent`, `high`, `normal`, `low`, `languid`.
Wait until all currently queued events with the given priority are processed.

`wait_for_no_initializing_shards`::
A boolean value which controls whether to wait (until the timeout provided)
for the cluster to have no shard initializations. Defaults to false, which means
it will not wait for initializing shards.

`wait_for_active_shards`::
A number controlling to how many active shards to wait for, `all` to wait
for all shards in the cluster to be active, or `0` to not wait. Defaults to `0`.
`wait_for_no_relocating_shards`::
A boolean value which controls whether to wait (until the timeout provided)
for the cluster to have no shard relocations. Defaults to false, which means
it will not wait for relocating shards.

`wait_for_nodes`::
The request waits until the specified number `N` of
nodes is available. It also accepts `>=N`, `<=N`, `>N` and `<N`.
Alternatively, it is possible to use `ge(N)`, `le(N)`, `gt(N)` and
`lt(N)` notation.

`wait_for_events`::
Can be one of `immediate`, `urgent`, `high`, `normal`, `low`, `languid`.
Wait until all currently queued events with the given priority are processed.

`timeout`::
A time based parameter controlling how long to wait if one of
the wait_for_XXX are provided. Defaults to `30s`.

`master_timeout`::
A time based parameter controlling how long to wait if the master has not been
discovered yet or disconnected.
If not provided, uses the same value as `timeout`.

`local`::
If `true` returns the local node information and does not provide
the state from master node. Default: `false`.
`wait_for_status`::
One of `green`, `yellow` or `red`. Will wait (until
the timeout provided) until the status of the cluster changes to the one
provided or better, i.e. `green` > `yellow` > `red`. By default, will not
wait for any status.

[[cluster-health-api-example]]
==== {api-examples-title}

The following is an example of getting the cluster health at the
`shards` level:
Expand Down
58 changes: 30 additions & 28 deletions docs/reference/cluster/state.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,18 @@
[[cluster-state]]
=== Cluster State

[[cluster-state-api-request]]
==== {api-request-title}

`GET /_cluster/state` +

`GET /_cluster/state/{metrics}` +

`GET /_cluster/state/{metrics}/{indices}`

[[cluster-state-api-desc]]
==== {api-description-title}

The cluster state API allows access to metadata representing the state of the
whole cluster. This includes information such as

Expand All @@ -18,12 +30,6 @@ 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.

Expand All @@ -38,28 +44,29 @@ 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
[[cluster-state-api-path-params]]
==== {api-path-parms-title}

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.
`{metrics}` is a comma-separated list of the following options:

`version`::
Shows the cluster state version.
`_all`::
Shows all metrics.

`blocks`::
Shows the `blocks` part of the response.

`master_node`::
Shows the elected `master_node` part of the response

`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.

`nodes`::
Shows the `nodes` part of the response
Expand All @@ -68,17 +75,12 @@ GET /_cluster/state/{metrics}/{indices}
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.

`version`::
Shows the cluster state version.

`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.
[[cluster-state-api-example]]
==== {api-examples-title}

The following example returns only `metadata` and `routing_table` data for the
`foo` and `bar` indices:
Expand Down