github-mirrors/kibana
1
0
Fork 0
mirror of https://github.com/elastic/kibana.git synced 2025-04-23 17:28:26 -04:00
Code Issues Projects Releases Packages Wiki Activity

[DOCS] Adds information about freeze action and index priority to docs (#30865)

Browse source 
* [DOCS] Adds information about freeze action and index priority to ILM docs

* [DOCS] Incorporates review changes for create policy doc
This commit is contained in:
gchaps 2019-02-13 05:58:02 -08:00 • committed by gchaps
parent 6c5a718720
commit b06f20fa17
1 changed files with 19 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

23
docs/management/index-lifecycle-policies/create-policy.asciidoc
View file

@ -21,11 +21,13 @@ disable *Index Management*, then *Index Lifecycle Policies* is also disabled.
[role="screenshot"]
image::images/index-lifecycle-policies-create.png[][UI for creating an index lifecycle policy]
==== Defining the phases of the index lifecycle
You can define up to four phases in the index lifecycle. For each phase, you
can enable actions to optimize performance for that phase. Transitioning
between phases is based on the age of the index.
The four phases of an index lifecycle policy are:
The four phases in the index lifecycle are:
* *Hot.* The index is actively being queried and written to. You can optionally
roll over to a new index when the
@ -35,8 +37,8 @@ index. You can still query the previous indices, but you only ever write to
the “hot” index. See {ref}/indices-rollover-index.html[Rollover index] for more information.
* *Warm.* The index is typically searched at a lower rate than when the data is
hot. The index is not used for storing for new data, but might occasionally add
late-arriving data, for example, from a Beat that had a network problem that's now fixed.
hot. The index is not used for storing new data, but might occasionally add
late-arriving data, for example, from a Beat with a network problem that's now fixed.
You can optionally shrink the number replicas and move the shards to a
different set of nodes with smaller or less performant hardware. You can also
reduce the number of primary shards and force merge the index into
@ -45,7 +47,10 @@ smaller {ref}/indices-segments.html[segments].
* *Cold.* The index is no longer being updated and is seldom queried, but is
still searchable. If you have a big deployment, you can move it to even
less performant hardware. You might also reduce the number of replicas because
you expect the data to be queried less frequently.
you expect the data to be queried less frequently. To keep the index searchable
for a longer period, and reduce the hardware requirements, you can use the
{ref}/frozen-indices.html[freeze action]. Queries are slower on a frozen index because the index is
reloaded from the disk to RAM on demand.
* *Delete.* The index is no longer relevant. You can define when it is safe to
delete it.
@ -55,3 +60,13 @@ delete phases are optional. For example, you might define all four phases for
one policy and only a hot and delete phase for another. See {ref}/_actions.html[Actions]
for more information on the actions available in each phase.
==== Setting the index priority
For the hot, warm, and cold phases, you can set a priority for recovering
indices after a node restart. Indices with higher priorities are recovered
before indices with lower priorities. By default, the index priority is set to
100 in the hot phase, 50 in the warm phase, and 0 in the cold phase.
If the cold phase of one index has data that
is more important than the data in the hot phase of another, you might increase
the index priority in the cold phase. See
{ref}/recovery-prioritization.html[Index recovery prioritization].