12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697 |
- [[cluster-health]]
- == Cluster Health
- The cluster health API allows to get a very simple status on the health
- of the cluster.
- [source,js]
- --------------------------------------------------
- $ curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'
- {
- "cluster_name" : "testcluster",
- "status" : "green",
- "timed_out" : false,
- "number_of_nodes" : 2,
- "number_of_data_nodes" : 2,
- "active_primary_shards" : 5,
- "active_shards" : 10,
- "relocating_shards" : 0,
- "initializing_shards" : 0,
- "unassigned_shards" : 0,
- "delayed_unassigned_shards": 0,
- "number_of_pending_tasks" : 0,
- "number_of_in_flight_fetch": 0,
- "task_max_waiting_in_queue_millis": 0,
- "active_shards_percent_as_number": 100
- }
- --------------------------------------------------
- The API can also be executed against one or more indices to get just the
- specified indices health:
- [source,js]
- --------------------------------------------------
- $ curl -XGET 'http://localhost:9200/_cluster/health/test1,test2'
- --------------------------------------------------
- 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]
- --------------------------------------------------
- $ curl -XGET 'http://localhost:9200/_cluster/health?wait_for_status=yellow&timeout=50s'
- --------------------------------------------------
- [float]
- [[request-params]]
- === Request Parameters
- The cluster health API accepts the following request 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.
- `wait_for_relocating_shards`::
- A number controlling to how many relocating
- shards to wait for. Usually will be `0` to indicate to wait till all
- relocations have happened. Defaults to not wait.
- `wait_for_active_shards`::
- A number controlling to how many active
- shards to wait for. Defaults to not wait.
- `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.
- `timeout`::
- A time based parameter controlling how long to wait if one of
- the wait_for_XXX are provided. Defaults to `30s`.
- The following is an example of getting the cluster health at the
- `shards` level:
- [source,js]
- --------------------------------------------------
- $ curl -XGET 'http://localhost:9200/_cluster/health/twitter?level=shards'
- --------------------------------------------------
|