health.asciidoc 3.8 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586
  1. [[cluster-health]]
  2. == Cluster Health
  3. The cluster health API allows to get a very simple status on the health
  4. of the cluster.
  5. [source,js]
  6. --------------------------------------------------
  7. $ curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'
  8. {
  9. "cluster_name" : "testcluster",
  10. "status" : "green",
  11. "timed_out" : false,
  12. "number_of_nodes" : 2,
  13. "number_of_data_nodes" : 2,
  14. "active_primary_shards" : 5,
  15. "active_shards" : 10,
  16. "relocating_shards" : 0,
  17. "initializing_shards" : 0,
  18. "unassigned_shards" : 0
  19. }
  20. --------------------------------------------------
  21. The API can also be executed against one or more indices to get just the
  22. specified indices health:
  23. [source,js]
  24. --------------------------------------------------
  25. $ curl -XGET 'http://localhost:9200/_cluster/health/test1,test2'
  26. --------------------------------------------------
  27. The cluster health status is: `green`, `yellow` or `red`. On the shard
  28. level, a `red` status indicates that the specific shard is not allocated
  29. in the cluster, `yellow` means that the primary shard is allocated but
  30. replicas are not, and `green` means that all shards are allocated. The
  31. index level status is controlled by the worst shard status. The cluster
  32. status is controlled by the worst index status.
  33. One of the main benefits of the API is the ability to wait until the
  34. cluster reaches a certain high water-mark health level. For example, the
  35. following will wait till the cluster reaches the `yellow` level for 50
  36. seconds (if it reaches the `green` or `yellow` status beforehand, it
  37. will return):
  38. [source,js]
  39. --------------------------------------------------
  40. $ curl -XGET 'http://localhost:9200/_cluster/health?wait_for_status=yellow&timeout=50s'
  41. --------------------------------------------------
  42. [float]
  43. === Request Parameters
  44. The cluster health API accepts the following request parameters:
  45. `level`::
  46. Can be one of `cluster`, `indices` or `shards`. Controls the
  47. details level of the health information returned. Defaults to `cluster`.
  48. `wait_for_status`::
  49. One of `green`, `yellow` or `red`. Will wait (until
  50. the timeout provided) until the status of the cluster changes to the one
  51. provided. By default, will not wait for any status.
  52. `wait_for_relocating_shards`::
  53. A number controlling to how many relocating
  54. shards to wait for. Usually will be `0` to indicate to wait till all
  55. relocation have happened. Defaults to not to wait.
  56. `wait_for_nodes`::
  57. The request waits until the specified number `N` of
  58. nodes is available. It also accepts `>=N`, `<=N`, `>N` and `<N`.
  59. Alternatively, it is possible to use `ge(N)`, `le(N)`, `gt(N)` and
  60. `lt(N)` notation.
  61. `timeout`::
  62. A time based parameter controlling how long to wait if one of
  63. the wait_for_XXX are provided. Defaults to `30s`.
  64. The following is an example of getting the cluster health at the
  65. `shards` level:
  66. [source,js]
  67. --------------------------------------------------
  68. $ curl -XGET 'http://localhost:9200/_cluster/health/twitter?level=shards'
  69. --------------------------------------------------