error-handling.asciidoc 5.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164
  1. [role="xpack"]
  2. [testenv="basic"]
  3. [[index-lifecycle-error-handling]]
  4. == Index Lifecycle Error Handling
  5. beta[]
  6. During Index Lifecycle Management's execution of the policy for an index, it's
  7. possible for a step to encounter an error during its execution. When this
  8. happens, ILM will move the management state into an "error" step. This halts
  9. further execution of the policy and gives an administrator the chance to address
  10. any issues with the policy, index, or cluster.
  11. An example will be helpful in illustrating this, imagine the following policy
  12. has been created by a user:
  13. [source,js]
  14. --------------------------------------------------
  15. PUT _ilm/policy/shrink-the-index
  16. {
  17. "policy": {
  18. "phases": {
  19. "warm": {
  20. "min_age": "5d",
  21. "actions": {
  22. "shrink": {
  23. "number_of_shards": 4
  24. }
  25. }
  26. }
  27. }
  28. }
  29. }
  30. --------------------------------------------------
  31. // CONSOLE
  32. // TEST
  33. This policy waits until the index is at least 5 days old, and then shrinks
  34. the index to 4 shards.
  35. Now imagine that a user creates a new index "myindex" with two primary shards,
  36. telling it to use the policy they have created:
  37. [source,js]
  38. --------------------------------------------------
  39. PUT /myindex
  40. {
  41. "settings": {
  42. "index.number_of_shards": 2,
  43. "index.lifecycle.name": "shrink-the-index"
  44. }
  45. }
  46. --------------------------------------------------
  47. // CONSOLE
  48. // TEST[continued]
  49. After five days have passed, ILM will attempt to shrink this index from 2
  50. shards to 4, which is invalid since the shrink action cannot increase the
  51. number of shards. When this occurs, ILM will move this
  52. index to the "error" step. Once an index is in this step, information about the
  53. reason for the error can be retrieved from the <<ilm-explain-lifecycle,ILM Explain API>>:
  54. [source,js]
  55. --------------------------------------------------
  56. GET /myindex/_ilm/explain
  57. --------------------------------------------------
  58. // CONSOLE
  59. // TEST[continued]
  60. Which returns the following information:
  61. [source,js]
  62. --------------------------------------------------
  63. {
  64. "indices" : {
  65. "myindex" : {
  66. "index" : "myindex",
  67. "managed" : true, <1>
  68. "policy" : "shrink-the-index", <2>
  69. "lifecycle_date_millis" : 1541717265865,
  70. "phase" : "warm", <3>
  71. "phase_time_millis" : 1541717272601,
  72. "action" : "shrink", <4>
  73. "action_time_millis" : 1541717272601,
  74. "step" : "ERROR", <5>
  75. "step_time_millis" : 1541717272688,
  76. "failed_step" : "shrink", <6>
  77. "step_info" : {
  78. "type" : "illegal_argument_exception", <7>
  79. "reason" : "the number of target shards [4] must be less that the number of source shards [2]" <8>
  80. },
  81. "phase_execution" : {
  82. "policy" : "shrink-the-index",
  83. "phase_definition" : { <9>
  84. "min_age" : "5d",
  85. "actions" : {
  86. "shrink" : {
  87. "number_of_shards" : 4
  88. }
  89. }
  90. },
  91. "version" : 1,
  92. "modified_date_in_millis" : 1541717264230
  93. }
  94. }
  95. }
  96. }
  97. --------------------------------------------------
  98. // CONSOLE
  99. // TESTRESPONSE[skip:no way to know if we will get this response immediately]
  100. <1> this index is managed by ILM
  101. <2> the policy in question, in this case, "shrink-the-index"
  102. <3> what phase the index is currently in
  103. <4> what action the index is currently on
  104. <5> what step the index is currently on, in this case, because there is an error, the index is in the "ERROR" step
  105. <6> the name of the step that failed to execute, in this case "shrink"
  106. <7> the error class that occurred during this step
  107. <8> the error message that occurred during the execution failure
  108. <9> the definition of the phase (in this case, the "warm" phase) that the index is currently on
  109. The index here has been moved to the error step because the shrink definition in
  110. the policy is using an incorrect number of shards. So rectifing that in the
  111. policy entails updating the existing policy to use one instead of four for
  112. the targeted number of shards.
  113. [source,js]
  114. --------------------------------------------------
  115. PUT _ilm/policy/shrink-the-index
  116. {
  117. "policy": {
  118. "phases": {
  119. "warm": {
  120. "min_age": "5d",
  121. "actions": {
  122. "shrink": {
  123. "number_of_shards": 1
  124. }
  125. }
  126. }
  127. }
  128. }
  129. }
  130. --------------------------------------------------
  131. // CONSOLE
  132. // TEST[continued]
  133. [float]
  134. === Retrying failed index lifecycle management steps
  135. Once the underlying issue that caused an index to move to the error step has
  136. been corrected, index lifecycle management must be told to retry the step to see
  137. if it can progress further. This is accomplished by invoking the retry API
  138. [source,js]
  139. --------------------------------------------------
  140. POST /myindex/_ilm/retry
  141. --------------------------------------------------
  142. // CONSOLE
  143. // TEST[skip:we can't be sure the index is ready to be retried at this point]
  144. Once this has been issue, index lifecycle management will asynchronously pick up
  145. on the step that is in a failed state, attempting to re-run it. The
  146. <<ilm-explain-lifecycle,ILM Explain API>> can again be used to monitor the status of
  147. re-running the step.