overview-ilm.asciidoc 2.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869
  1. [role="xpack"]
  2. [testenv="basic"]
  3. [[overview-index-lifecycle-management]]
  4. == Index lifecycle management overview
  5. ++++
  6. <titleabbrev>Overview</titleabbrev>
  7. ++++
  8. You can create and apply {ilm-cap} ({ilm-init}) policies to automatically manage your indices
  9. according to your performance, resiliency, and retention requirements.
  10. Index lifecycle policies can trigger actions such as:
  11. * **Rollover** -
  12. include::../glossary.asciidoc[tag=rollover-def-short]
  13. * **Shrink** -
  14. include::../glossary.asciidoc[tag=shrink-def-short]
  15. * **Force merge** -
  16. include::../glossary.asciidoc[tag=force-merge-def-short]
  17. * **Freeze** -
  18. include::../glossary.asciidoc[tag=freeze-def-short]
  19. * **Delete** - Permanently remove an index, including all of its data and metadata.
  20. Typically, you associate a lifecycle policy with an index template so it is automatically applied
  21. to new indices.
  22. You can also apply a policy manually when you create an index.
  23. {ilm-init} simplifies managing indices in hot-warm-cold architectures,
  24. which are common when you're working with time-series data such as logs and metrics.
  25. As an index ages, it moves through four possible phases:
  26. * Hot--the index is actively being updated and queried.
  27. * Warm--the index is no longer being updated, but is still being queried.
  28. * Cold--the index is no longer being updated and is seldom queried. The
  29. information still needs to be searchable, but it's okay if those queries are
  30. slower.
  31. * Delete--the index is no longer needed and can safely be deleted.
  32. A lifecycle policy controls how an index moves between phases and
  33. what actions to perform during each phase. You can specify:
  34. * The maximum size or age at which you want to roll over to a new index.
  35. * The point at which the index is no longer being updated and the number of
  36. primary shards can be reduced.
  37. * When to force a merge to permanently delete documents marked for deletion.
  38. * The point at which the index can be moved to less performant hardware.
  39. * The point at which the availability is not as critical and the number of
  40. replicas can be reduced.
  41. * When the index can be safely deleted.
  42. For example, if you are indexing metrics data from a fleet of ATMs into
  43. Elasticsearch, you might define a policy that says:
  44. . When the index reaches 50GB, roll over to a new index.
  45. . Move the old index into the warm stage, mark it read only, and shrink it down
  46. to a single shard.
  47. . After 7 days, move the index into the cold stage and move it to less expensive
  48. hardware.
  49. . Delete the index once the required 30 day retention period is reached.
  50. [IMPORTANT]
  51. ===========================
  52. To use {ilm-init}, all nodes in a cluster must run the same version.
  53. Although it might be possible to create and apply policies in a mixed-version cluster,
  54. there is no guarantee they will work as intended.
  55. Attempting to use a policy that contains actions that aren't
  56. supported on all nodes in a cluster will cause errors.
  57. ===========================