OpenSearch/docs/reference/ilm/ilm-overview.asciidoc
debadair 100d2bd063
[DOCS] Editorial ILM cleanup (#57565) (#57776)
* [DOCS] Editorial cleanup

* Moved example of applying a template to multiple indices.

* Combine existing indices topics

* Fixed test

* Add skip rollover file.

* Revert rename.

* Update include.

* Revert rename

* Apply suggestions from code review

Co-authored-by: Adam Locke <adam.locke@elastic.co>
Co-authored-by: Lee Hinman <dakrone@users.noreply.github.com>

* Apply suggestions from code review

* Fixed callout

* Update docs/reference/ilm/ilm-with-existing-indices.asciidoc

Co-authored-by: Lee Hinman <dakrone@users.noreply.github.com>

* Update docs/reference/ilm/ilm-with-existing-indices.asciidoc

Co-authored-by: Lee Hinman <dakrone@users.noreply.github.com>

* Apply suggestions from code review

* Restored policy to template example.

* Fixed JSON parse error

Co-authored-by: Adam Locke <adam.locke@elastic.co>
Co-authored-by: Lee Hinman <dakrone@users.noreply.github.com>

Co-authored-by: Adam Locke <adam.locke@elastic.co>
Co-authored-by: Lee Hinman <dakrone@users.noreply.github.com>
2020-06-05 18:55:51 -07:00

56 lines
2.2 KiB
Plaintext

[role="xpack"]
[testenv="basic"]
[[overview-index-lifecycle-management]]
== {ilm-init} overview
++++
<titleabbrev>Overview</titleabbrev>
++++
You can create and apply {ilm-cap} ({ilm-init}) policies to automatically manage your indices
according to your performance, resiliency, and retention requirements.
Index lifecycle policies can trigger actions such as:
* **Rollover**:
include::../glossary.asciidoc[tag=rollover-def-short]
* **Shrink**:
include::../glossary.asciidoc[tag=shrink-def-short]
* **Force merge**:
include::../glossary.asciidoc[tag=force-merge-def-short]
* **Freeze**:
include::../glossary.asciidoc[tag=freeze-def-short]
* **Delete**: Permanently remove an index, including all of its data and metadata.
{ilm-init} makes it easier to manage indices in hot-warm-cold architectures,
which are common when you're working with time-series data such as logs and metrics.
You can specify:
* The maximum shard size, number of documents, 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 remove 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 50GB, 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.
[IMPORTANT]
===========================
To use {ilm-init}, all nodes in a cluster must run the same version.
Although it might be possible to create and apply policies in a mixed-version cluster,
there is no guarantee they will work as intended.
Attempting to use a policy that contains actions that aren't
supported on all nodes in a cluster will cause errors.
===========================