2018-10-26 15:19:52 -04:00
|
|
|
[role="xpack"]
|
|
|
|
[testenv="basic"]
|
2018-08-13 16:15:15 -04:00
|
|
|
[[index-lifecycle-management]]
|
2018-11-08 18:26:27 -05:00
|
|
|
= Managing the index lifecycle
|
2018-08-13 16:15:15 -04:00
|
|
|
|
|
|
|
:ilm: index lifecycle management
|
2018-11-08 18:26:27 -05:00
|
|
|
:Ilm: Index lifecycle management
|
|
|
|
:ILM: ILM
|
2018-08-13 16:15:15 -04:00
|
|
|
[partintro]
|
|
|
|
--
|
2018-11-16 13:49:55 -05:00
|
|
|
beta[]
|
|
|
|
|
2018-11-08 18:26:27 -05:00
|
|
|
The <<index-lifecycle-management-api, {ilm} (ILM) APIs>> enable you to automate how you
|
2018-10-30 21:27:43 -04:00
|
|
|
want to manage your indices over time. Rather than simply performing management
|
|
|
|
actions on your indices on a set schedule, you can base actions on other factors
|
|
|
|
such as shard size and performance requirements.
|
2018-08-13 16:15:15 -04:00
|
|
|
|
|
|
|
You control how indices are handled as they age by attaching a
|
|
|
|
lifecycle policy to the index template used to create them. You can update
|
|
|
|
the policy to modify the lifecycle of both new and existing indices.
|
|
|
|
|
|
|
|
For time series indices, there are four stages in the index lifecycle:
|
|
|
|
|
|
|
|
* Hot--the index is actively being updated and queried.
|
|
|
|
* Warm--the index is no longer being updated, but is still being queried.
|
|
|
|
* Cold--the index is no longer being updated and is seldom queried. The
|
|
|
|
information still needs to be searchable, but it's okay if those queries are
|
|
|
|
slower.
|
|
|
|
* Delete--the index is no longer needed and can safely be deleted.
|
|
|
|
|
|
|
|
The lifecycle policy governs how the index transitions through these stages and
|
|
|
|
the actions that are performed on the index at each stage. The policy can
|
|
|
|
specify:
|
|
|
|
|
|
|
|
* The maximum size or age at which you want to roll over to a new index.
|
|
|
|
* The point at which the index is no longer being updated and the number of
|
|
|
|
primary shards can be reduced.
|
|
|
|
* When to force a merge to permanently delete documents marked for deletion.
|
|
|
|
* The point at which the index can be moved to less performant hardware.
|
|
|
|
* The point at which the availability is not as critical and the number of
|
|
|
|
replicas can be reduced.
|
|
|
|
* When the index can be safely deleted.
|
|
|
|
|
|
|
|
For example, if you are indexing metrics data from a fleet of ATMs into
|
|
|
|
Elasticsearch, you might define a policy that says:
|
|
|
|
|
|
|
|
. When the index reaches 5GB, roll over to a new index.
|
|
|
|
. Move the old index into the warm stage, mark it read only, and shrink it down
|
|
|
|
to a single shard.
|
|
|
|
. After 7 days, move the index into the cold stage and move it to less expensive
|
|
|
|
hardware.
|
|
|
|
. Delete the index once the required 30 day retention period is reached.
|
|
|
|
--
|
|
|
|
|
|
|
|
include::getting-started-ilm.asciidoc[]
|
|
|
|
|
2018-11-14 12:23:50 -05:00
|
|
|
include::policy-definitions.asciidoc[]
|
2018-08-13 16:15:15 -04:00
|
|
|
|
|
|
|
include::set-up-lifecycle-policy.asciidoc[]
|
|
|
|
|
2018-11-14 12:23:50 -05:00
|
|
|
include::using-policies-rollover.asciidoc[]
|
|
|
|
|
2018-08-13 16:15:15 -04:00
|
|
|
include::update-lifecycle-policy.asciidoc[]
|
|
|
|
|
2018-11-13 14:19:22 -05:00
|
|
|
include::error-handling.asciidoc[]
|
|
|
|
|
2018-11-30 14:06:48 -05:00
|
|
|
include::ilm-and-snapshots.asciidoc[]
|
|
|
|
|
2018-10-25 10:30:53 -04:00
|
|
|
include::start-stop-ilm.asciidoc[]
|