example-watch-clusterstatus.asciidoc 8.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283
  1. [role="xpack"]
  2. [[watch-cluster-status]]
  3. === Watching the status of an Elasticsearch cluster
  4. You can easily configure a basic watch to monitor the health of your
  5. Elasticsearch cluster:
  6. * <<health-add-input,Schedule the watch and define an input>> that gets the
  7. cluster health status.
  8. * <<health-add-condition,Add a condition>> that evaluates the health status to
  9. determine if action is required.
  10. * <<health-take-action,Take action>> if the cluster is RED.
  11. [float]
  12. [[health-add-input]]
  13. ==== Schedule the watch and add an input
  14. A watch <<trigger-schedule,schedule>> controls how often a watch is triggered.
  15. The watch <<input,input>> gets the data that you want to evaluate.
  16. The simplest way to define a schedule is to specify an interval. For example,
  17. the following schedule runs every 10 seconds:
  18. [source,console]
  19. --------------------------------------------------
  20. PUT _watcher/watch/cluster_health_watch
  21. {
  22. "trigger" : {
  23. "schedule" : { "interval" : "10s" } <1>
  24. }
  25. }
  26. --------------------------------------------------
  27. <1> Schedules are typically configured to run less frequently. This example sets
  28. the interval to 10 seconds to you can easily see the watches being triggered.
  29. Since this watch runs so frequently, don't forget to <<health-delete, delete the watch>>
  30. when you're done experimenting.
  31. To get the status of your cluster, you can call the Elasticsearch
  32. {ref}//cluster-health.html[cluster health] API:
  33. [source,console]
  34. --------------------------------------------------
  35. GET _cluster/health?pretty
  36. --------------------------------------------------
  37. // TEST[continued]
  38. To load the health status into your watch, you simply add an
  39. <<input-http,HTTP input>> that calls the cluster health API:
  40. [source,console]
  41. --------------------------------------------------
  42. PUT _watcher/watch/cluster_health_watch
  43. {
  44. "trigger" : {
  45. "schedule" : { "interval" : "10s" }
  46. },
  47. "input" : {
  48. "http" : {
  49. "request" : {
  50. "host" : "localhost",
  51. "port" : 9200,
  52. "path" : "/_cluster/health"
  53. }
  54. }
  55. }
  56. }
  57. --------------------------------------------------
  58. If you're using Security, then you'll also need to supply some authentication
  59. credentials as part of the watch configuration:
  60. [source,console]
  61. --------------------------------------------------
  62. PUT _watcher/watch/cluster_health_watch
  63. {
  64. "trigger" : {
  65. "schedule" : { "interval" : "10s" }
  66. },
  67. "input" : {
  68. "http" : {
  69. "request" : {
  70. "host" : "localhost",
  71. "port" : 9200,
  72. "path" : "/_cluster/health",
  73. "auth": {
  74. "basic": {
  75. "username": "elastic",
  76. "password": "x-pack-test-password"
  77. }
  78. }
  79. }
  80. }
  81. }
  82. }
  83. --------------------------------------------------
  84. It would be a good idea to create a user with the minimum privileges required
  85. for use with such a watch configuration.
  86. Depending on how your cluster is configured, there may be additional settings
  87. required before the watch can access your cluster such as keystores, truststores,
  88. or certificates. For more information, see <<notification-settings>>.
  89. If you check the watch history, you'll see that the cluster status is recorded
  90. as part of the `watch_record` each time the watch executes.
  91. For example, the following request retrieves the last ten watch records from
  92. the watch history:
  93. [source,console]
  94. --------------------------------------------------
  95. GET .watcher-history*/_search
  96. {
  97. "sort" : [
  98. { "result.execution_time" : "desc" }
  99. ]
  100. }
  101. --------------------------------------------------
  102. // TEST[continued]
  103. [float]
  104. [[health-add-condition]]
  105. ==== Add a condition
  106. A <<condition,condition>> evaluates the data you've loaded into the watch and
  107. determines if any action is required. Since you've defined an input that loads
  108. the cluster status into the watch, you can define a condition that checks that
  109. status.
  110. For example, you could add a condition to check to see if the status is RED.
  111. [source,console]
  112. --------------------------------------------------
  113. PUT _watcher/watch/cluster_health_watch
  114. {
  115. "trigger" : {
  116. "schedule" : { "interval" : "10s" } <1>
  117. },
  118. "input" : {
  119. "http" : {
  120. "request" : {
  121. "host" : "localhost",
  122. "port" : 9200,
  123. "path" : "/_cluster/health"
  124. }
  125. }
  126. },
  127. "condition" : {
  128. "compare" : {
  129. "ctx.payload.status" : { "eq" : "red" }
  130. }
  131. }
  132. }
  133. --------------------------------------------------
  134. <1> Schedules are typically configured to run less frequently. This example sets
  135. the interval to 10 seconds to you can easily see the watches being triggered.
  136. If you check the watch history, you'll see that the condition result is recorded
  137. as part of the `watch_record` each time the watch executes.
  138. To check to see if the condition was met, you can run the following query.
  139. [source,console]
  140. ------------------------------------------------------
  141. GET .watcher-history*/_search?pretty
  142. {
  143. "query" : {
  144. "match" : { "result.condition.met" : true }
  145. }
  146. }
  147. ------------------------------------------------------
  148. // TEST[continued]
  149. [float]
  150. [[health-take-action]]
  151. ==== Take action
  152. Recording `watch_records` in the watch history is nice, but the real power of
  153. {watcher} is being able to do something in response to an alert. A watch's
  154. <<actions,actions>> define what to do when the watch condition is true--you
  155. can send emails, call third-party webhooks, or write documents to an
  156. Elasticsearch index or log when the watch condition is met.
  157. For example, you could add an action to index the cluster status information
  158. when the status is RED.
  159. [source,console]
  160. --------------------------------------------------
  161. PUT _watcher/watch/cluster_health_watch
  162. {
  163. "trigger" : {
  164. "schedule" : { "interval" : "10s" }
  165. },
  166. "input" : {
  167. "http" : {
  168. "request" : {
  169. "host" : "localhost",
  170. "port" : 9200,
  171. "path" : "/_cluster/health"
  172. }
  173. }
  174. },
  175. "condition" : {
  176. "compare" : {
  177. "ctx.payload.status" : { "eq" : "red" }
  178. }
  179. },
  180. "actions" : {
  181. "send_email" : {
  182. "email" : {
  183. "to" : "username@example.org",
  184. "subject" : "Cluster Status Warning",
  185. "body" : "Cluster status is RED"
  186. }
  187. }
  188. }
  189. }
  190. --------------------------------------------------
  191. For {watcher} to send email, you must configure an email account in your
  192. `elasticsearch.yml` configuration file and restart Elasticsearch. To add an email
  193. account, set the `xpack.notification.email.account` property.
  194. For example, the following snippet configures a single Gmail account named `work`:
  195. [source,yaml]
  196. ----------------------------------------------------------
  197. xpack.notification.email.account:
  198. work:
  199. profile: gmail
  200. email_defaults:
  201. from: <email> <1>
  202. smtp:
  203. auth: true
  204. starttls.enable: true
  205. host: smtp.gmail.com
  206. port: 587
  207. user: <username> <2>
  208. password: <password> <3>
  209. ----------------------------------------------------------
  210. <1> Replace `<email>` with the email address from which you want to send
  211. notifications.
  212. <2> Replace `<username>` with your Gmail user name (typically your Gmail address).
  213. <3> Replace `<password>` with your Gmail password.
  214. NOTE: If you have advanced security options enabled for your email account,
  215. you need to take additional steps to send email from {watcher}. For more
  216. information, see <<configuring-email>>.
  217. You can check the watch history or the `status_index` to see that the action was
  218. performed.
  219. [source,console]
  220. -------------------------------------------------------
  221. GET .watcher-history*/_search?pretty
  222. {
  223. "query" : {
  224. "match" : { "result.condition.met" : true }
  225. }
  226. }
  227. -------------------------------------------------------
  228. // TEST[continued]
  229. [float]
  230. [[health-delete]]
  231. ==== Delete the watch
  232. Since the `cluster_health_watch` is configured to run every 10 seconds, make
  233. sure you delete it when you're done experimenting. Otherwise, you'll spam yourself
  234. indefinitely.
  235. To remove the watch, use the <<watcher-api-delete-watch,delete watch API>>:
  236. [source,console]
  237. -------------------------------------------------------
  238. DELETE _watcher/watch/cluster_health_watch
  239. -------------------------------------------------------
  240. // TEST[continued]