health.asciidoc 6.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195
  1. [[cluster-health]]
  2. === Cluster health API
  3. ++++
  4. <titleabbrev>Cluster health</titleabbrev>
  5. ++++
  6. Returns the health status of a cluster.
  7. [[cluster-health-api-request]]
  8. ==== {api-request-title}
  9. `GET /_cluster/health/<target>`
  10. [[cluster-health-api-prereqs]]
  11. ==== {api-prereq-title}
  12. * If the {es} {security-features} are enabled, you must have the `monitor` or
  13. `manage` <<privileges-list-cluster,cluster privilege>> to use this API.
  14. [[cluster-health-api-desc]]
  15. ==== {api-description-title}
  16. The cluster health API returns a simple status on the health of the
  17. cluster. You can also use the API to get the health status of only specified
  18. data streams and indices. For data streams, the API retrieves the health status
  19. of the stream's backing indices.
  20. The cluster health status is: `green`, `yellow` or `red`. On the shard level, a
  21. `red` status indicates that the specific shard is not allocated in the cluster,
  22. `yellow` means that the primary shard is allocated but replicas are not, and
  23. `green` means that all shards are allocated. The index level status is
  24. controlled by the worst shard status. The cluster status is controlled by the
  25. worst index status.
  26. One of the main benefits of the API is the ability to wait until the cluster
  27. reaches a certain high water-mark health level. For example, the following will
  28. wait for 50 seconds for the cluster to reach the `yellow` level (if it reaches
  29. the `green` or `yellow` status before 50 seconds elapse, it will return at that
  30. point):
  31. [source,console]
  32. --------------------------------------------------
  33. GET /_cluster/health?wait_for_status=yellow&timeout=50s
  34. --------------------------------------------------
  35. [[cluster-health-api-path-params]]
  36. ==== {api-path-parms-title}
  37. `<target>`::
  38. (Optional, string)
  39. Comma-separated list of data streams, indices, and index aliases used to limit
  40. the request. Wildcard expressions (`*`) are supported.
  41. +
  42. To target all data streams and indices in a cluster, omit this parameter or use
  43. `_all` or `*`.
  44. [[cluster-health-api-query-params]]
  45. ==== {api-query-parms-title}
  46. `level`::
  47. (Optional, string) Can be one of `cluster`, `indices` or `shards`. Controls
  48. the details level of the health information returned. Defaults to `cluster`.
  49. include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=local]
  50. include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=timeoutparms]
  51. `wait_for_active_shards`::
  52. (Optional, string) A number controlling to how many active shards to wait
  53. for, `all` to wait for all shards in the cluster to be active, or `0` to not
  54. wait. Defaults to `0`.
  55. `wait_for_events`::
  56. (Optional, string) Can be one of `immediate`, `urgent`, `high`, `normal`,
  57. `low`, `languid`. Wait until all currently queued events with the given
  58. priority are processed.
  59. `wait_for_no_initializing_shards`::
  60. (Optional, Boolean) A boolean value which controls whether to wait (until
  61. the timeout provided) for the cluster to have no shard initializations.
  62. Defaults to false, which means it will not wait for initializing shards.
  63. `wait_for_no_relocating_shards`::
  64. (Optional, Boolean) A boolean value which controls whether to wait (until
  65. the timeout provided) for the cluster to have no shard relocations. Defaults
  66. to false, which means it will not wait for relocating shards.
  67. `wait_for_nodes`::
  68. (Optional, string) The request waits until the specified number `N` of
  69. nodes is available. It also accepts `>=N`, `<=N`, `>N` and `<N`.
  70. Alternatively, it is possible to use `ge(N)`, `le(N)`, `gt(N)` and
  71. `lt(N)` notation.
  72. `wait_for_status`::
  73. (Optional, string) One of `green`, `yellow` or `red`. Will wait (until the
  74. timeout provided) until the status of the cluster changes to the one
  75. provided or better, i.e. `green` > `yellow` > `red`. By default, will not
  76. wait for any status.
  77. [[cluster-health-api-response-body]]
  78. ==== {api-response-body-title}
  79. `cluster_name`::
  80. (string) The name of the cluster.
  81. `status`::
  82. include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=cluster-health-status]
  83. `timed_out`::
  84. (Boolean) If `false` the response returned within the period of
  85. time that is specified by the `timeout` parameter (`30s` by default).
  86. `number_of_nodes`::
  87. (integer) The number of nodes within the cluster.
  88. `number_of_data_nodes`::
  89. (integer) The number of nodes that are dedicated data nodes.
  90. `active_primary_shards`::
  91. (integer) The number of active primary shards.
  92. `active_shards`::
  93. (integer) The total number of active primary and replica shards.
  94. `relocating_shards`::
  95. (integer) The number of shards that are under relocation.
  96. `initializing_shards`::
  97. (integer) The number of shards that are under initialization.
  98. `unassigned_shards`::
  99. (integer) The number of shards that are not allocated.
  100. `delayed_unassigned_shards`::
  101. (integer) The number of shards whose allocation has been delayed by the
  102. timeout settings.
  103. `number_of_pending_tasks`::
  104. (integer) The number of cluster-level changes that have not yet been
  105. executed.
  106. `number_of_in_flight_fetch`::
  107. (integer) The number of unfinished fetches.
  108. `task_max_waiting_in_queue_millis`::
  109. (integer) The time expressed in milliseconds since the earliest initiated task
  110. is waiting for being performed.
  111. `active_shards_percent_as_number`::
  112. (float) The ratio of active shards in the cluster expressed as a percentage.
  113. [[cluster-health-api-example]]
  114. ==== {api-examples-title}
  115. [source,console]
  116. --------------------------------------------------
  117. GET _cluster/health
  118. --------------------------------------------------
  119. // TEST[s/^/PUT test1\n/]
  120. The API returns the following response in case of a quiet single node cluster
  121. with a single index with one shard and one replica:
  122. [source,console-result]
  123. --------------------------------------------------
  124. {
  125. "cluster_name" : "testcluster",
  126. "status" : "yellow",
  127. "timed_out" : false,
  128. "number_of_nodes" : 1,
  129. "number_of_data_nodes" : 1,
  130. "active_primary_shards" : 1,
  131. "active_shards" : 1,
  132. "relocating_shards" : 0,
  133. "initializing_shards" : 0,
  134. "unassigned_shards" : 1,
  135. "delayed_unassigned_shards": 0,
  136. "number_of_pending_tasks" : 0,
  137. "number_of_in_flight_fetch": 0,
  138. "task_max_waiting_in_queue_millis": 0,
  139. "active_shards_percent_as_number": 50.0
  140. }
  141. --------------------------------------------------
  142. // TESTRESPONSE[s/testcluster/yamlRestTest/]
  143. // TESTRESPONSE[s/"number_of_pending_tasks" : 0,/"number_of_pending_tasks" : $body.number_of_pending_tasks,/]
  144. // TESTRESPONSE[s/"task_max_waiting_in_queue_millis": 0/"task_max_waiting_in_queue_millis": $body.task_max_waiting_in_queue_millis/]
  145. The following is an example of getting the cluster health at the
  146. `shards` level:
  147. [source,console]
  148. --------------------------------------------------
  149. GET /_cluster/health/my-index-000001?level=shards
  150. --------------------------------------------------
  151. // TEST[setup:my_index]