health.asciidoc 4.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119
  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. For example, on a quiet single node cluster with a single index
  5. with 5 shards and one replica, this:
  6. [source,js]
  7. --------------------------------------------------
  8. GET _cluster/health
  9. --------------------------------------------------
  10. // CONSOLE
  11. // TEST[s/^/PUT test1\n/]
  12. Returns this:
  13. [source,js]
  14. --------------------------------------------------
  15. {
  16. "cluster_name" : "testcluster",
  17. "status" : "yellow",
  18. "timed_out" : false,
  19. "number_of_nodes" : 1,
  20. "number_of_data_nodes" : 1,
  21. "active_primary_shards" : 5,
  22. "active_shards" : 5,
  23. "relocating_shards" : 0,
  24. "initializing_shards" : 0,
  25. "unassigned_shards" : 5,
  26. "delayed_unassigned_shards": 0,
  27. "number_of_pending_tasks" : 0,
  28. "number_of_in_flight_fetch": 0,
  29. "task_max_waiting_in_queue_millis": 0,
  30. "active_shards_percent_as_number": 50.0
  31. }
  32. --------------------------------------------------
  33. // TESTRESPONSE[s/testcluster/docs_integTestCluster/]
  34. // TESTRESPONSE[s/"number_of_pending_tasks" : 0,/"number_of_pending_tasks" : $body.number_of_pending_tasks,/]
  35. // TESTRESPONSE[s/"task_max_waiting_in_queue_millis": 0/"task_max_waiting_in_queue_millis": $body.task_max_waiting_in_queue_millis/]
  36. The API can also be executed against one or more indices to get just the
  37. specified indices health:
  38. [source,js]
  39. --------------------------------------------------
  40. GET /_cluster/health/test1,test2
  41. --------------------------------------------------
  42. // CONSOLE
  43. // TEST[s/^/PUT test1\nPUT test2\n/]
  44. The cluster health status is: `green`, `yellow` or `red`. On the shard
  45. level, a `red` status indicates that the specific shard is not allocated
  46. in the cluster, `yellow` means that the primary shard is allocated but
  47. replicas are not, and `green` means that all shards are allocated. The
  48. index level status is controlled by the worst shard status. The cluster
  49. status is controlled by the worst index status.
  50. One of the main benefits of the API is the ability to wait until the
  51. cluster reaches a certain high water-mark health level. For example, the
  52. following will wait for 50 seconds for the cluster to reach the `yellow`
  53. level (if it reaches the `green` or `yellow` status before 50 seconds elapse,
  54. it will return at that point):
  55. [source,js]
  56. --------------------------------------------------
  57. GET /_cluster/health?wait_for_status=yellow&timeout=50s
  58. --------------------------------------------------
  59. // CONSOLE
  60. [float]
  61. [[request-params]]
  62. === Request Parameters
  63. The cluster health API accepts the following request parameters:
  64. `level`::
  65. Can be one of `cluster`, `indices` or `shards`. Controls the
  66. details level of the health information returned. Defaults to `cluster`.
  67. `wait_for_status`::
  68. One of `green`, `yellow` or `red`. Will wait (until
  69. the timeout provided) until the status of the cluster changes to the one
  70. provided or better, i.e. `green` > `yellow` > `red`. By default, will not
  71. wait for any status.
  72. `wait_for_no_relocating_shards`::
  73. A boolean value which controls whether to wait (until the timeout provided)
  74. for the cluster to have no shard relocations. Defaults to false, which means
  75. it will not wait for relocating shards.
  76. `wait_for_active_shards`::
  77. A number controlling to how many active shards to wait for, `all` to wait
  78. for all shards in the cluster to be active, or `0` to not wait. Defaults to `0`.
  79. `wait_for_nodes`::
  80. The request waits until the specified number `N` of
  81. nodes is available. It also accepts `>=N`, `<=N`, `>N` and `<N`.
  82. Alternatively, it is possible to use `ge(N)`, `le(N)`, `gt(N)` and
  83. `lt(N)` notation.
  84. `timeout`::
  85. A time based parameter controlling how long to wait if one of
  86. the wait_for_XXX are provided. Defaults to `30s`.
  87. `local`::
  88. If `true` returns the local node information and does not provide
  89. the state from master node. Default: `false`.
  90. The following is an example of getting the cluster health at the
  91. `shards` level:
  92. [source,js]
  93. --------------------------------------------------
  94. GET /_cluster/health/twitter?level=shards
  95. --------------------------------------------------
  96. // CONSOLE
  97. // TEST[setup:twitter]