[DOCS] Combo version of ILM docs. (#57909) (#59029)

* [DOCS] Combo version of ILM docs.

* [DOCS] Moved tutorial from Kibana.

* Adds documentation for index lifecycle policies (#28705)

* [DOCS] Adds documentation for index lifecycle policies

* [DOCS] Updated image for policy options to show all menu items

* Update create-policy.asciidoc

* [DOCS] Incorporated review comments on hot and warm phase

* [DOCS] Additional changes to warm phase

* [DOCS] Removed the word open in the warm phase

* Adds X-Pack icon for ILM (#34178)

* Add ILM tutorial (#59502)

* Add tutorial for ILM with filebeat

* Change screenshots and add additional steps

* Update screenshots, add numbered steps, and other minor edits

* Incorporate feedback: update links, formatting, and minor edits

* Move tip inline with list

* Apply suggestions from code review

Co-Authored-By: James Rodewig <james.rodewig@elastic.co>

* Move TIP inline . . . again

* Put TIP inline

Co-authored-by: James Rodewig <james.rodewig@elastic.co>

* Updates for navigation redesign (#68709)

* [DOCS] Updates for navigation redesign

* Getting started

* Set up text

* Discover

* Dashboard, Graph, ML, Maps, APM, SIEM, Dev tools

* Dev Tools, Stack Monitoring, Management

* Management

* Final changes

* [DOCS] Updates for navigation redesign

* [DOCS] Updates CCR monitoring screenshots

* updates SIEM screenshot and Cases overview text

* Added Brandon's APM image

* [DOCS] Refines CCR shard screenshot

* Removed merge conflict image file

Co-authored-by: lcawl <lcawley@elastic.co>
Co-authored-by: Ben Skelker <ben.skelker@elastic.co>

* [DOCS] Put API examples in collapsible sections like ML does

* Fix include

* Added tutorial images

* Fixed images

* Add short title for FB tutorial

* Add missing files

* Incorporate review feedback

* review feedback

* Incorporated review feedback

Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com>
Co-authored-by: Lisa Cawley <lcawley@elastic.co>
Co-authored-by: Melori Arellano <melori@elastic.co>
Co-authored-by: James Rodewig <james.rodewig@elastic.co>
Co-authored-by: Kaarina Tungseth <kaarina.tungseth@elastic.co>
Co-authored-by: Ben Skelker <ben.skelker@elastic.co>

Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com>
Co-authored-by: Lisa Cawley <lcawley@elastic.co>
Co-authored-by: Melori Arellano <melori@elastic.co>
Co-authored-by: James Rodewig <james.rodewig@elastic.co>
Co-authored-by: Kaarina Tungseth <kaarina.tungseth@elastic.co>
Co-authored-by: Ben Skelker <ben.skelker@elastic.co>
This commit is contained in:
debadair 2020-07-03 13:01:08 -07:00 committed by GitHub
parent 7c43cbca82
commit c8e3128fe4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
16 changed files with 257 additions and 54 deletions

View File

@ -268,7 +268,6 @@ shard will never be started on the same node as its primary shard.
--
// tag::rollover-def[]
// tag::rollover-def-short[]
Creates a new index for a rollover target when the existing index reaches a certain size, number of docs, or age.
A rollover target can be either an <<indices-aliases, index alias>> or a <<data-streams, data stream>>.
// end::rollover-def-short[]

View File

@ -0,0 +1,165 @@
[role="xpack"]
[[example-using-index-lifecycle-policy]]
=== Tutorial: Manage {filebeat} time-based indices
++++
<titleabbrev>Manage {filebeat} time-based indices</titleabbrev>
++++
With {ilm} ({ilm-init}), you can create policies that perform actions automatically
on indices as they age and grow. {ilm-init} policies help you to manage
performance, resilience, and retention of your data during its lifecycle. This tutorial shows
you how to use {kib}s *Index Lifecycle Policies* to modify and create {ilm-init}
policies. You can learn more about all of the actions, benefits, and lifecycle
phases in the <<overview-index-lifecycle-management, {ilm-init} overview>>.
[discrete]
[[example-using-index-lifecycle-policy-scenario]]
==== Scenario
Youre tasked with sending syslog files to an {es} cluster. This
log data has the following data retention guidelines:
* Keep logs on hot data nodes for 30 days
* Roll over to a new index if the size reaches 50GB
* After 30 days:
** Move the logs to warm data nodes
** Set <<glossary-replica-shard, replica shards>> to 1
** <<indices-forcemerge, Force merge>> multiple index segments to free up the space used by deleted documents
* Delete logs after 90 days
[discrete]
[[example-using-index-lifecycle-policy-prerequisites]]
==== Prerequisites
To complete this tutorial, you'll need:
* An {es} cluster with hot and warm nodes configured for shard allocation
awareness.
** {ess}:
Choose the {cloud}/ec-getting-started-templates-hot-warm.html[hot-warm architecture] deployment template.
** Self-managed cluster:
Add node attributes as described for {ref}/shard-allocation-filtering.html[shard allocation filtering].
+
For example, you can set this in your `elasticsearch.yml` for each data node:
+
[source,yaml]
--------------------------------------------------------------------------------
node.attr.data: "warm"
--------------------------------------------------------------------------------
* A server with {filebeat} installed and configured to send logs to the `elasticsearch`
output as described in {filebeat-ref}/filebeat-getting-started.html[Getting Started with {filebeat}].
[discrete]
[[example-using-index-lifecycle-policy-view-fb-ilm-policy]]
==== View the {filebeat} {ilm-init} policy
{filebeat} includes a default {ilm-init} policy that enables rollover. {ilm-init}
is enabled automatically if youre using the default `filebeat.yml` and index template.
To view the default policy in {kib}:
. Go to Management and select *Index Lifecycle Policies*.
. Search for _filebeat_
. Select the _filebeat-version_ policy.
This policy initiates the rollover action when the index size reaches 50GB or
becomes 30 days old.
[role="screenshot"]
image::images/ilm/tutorial-ilm-hotphaserollover-default.png["Default policy"]
[discrete]
==== Modify the policy
The default policy is enough to prevent the creation of many tiny daily indices.
You can modify the policy to meet more complex requirements.
. Activate the warm phase.
+
--
[role="screenshot"]
image::images/ilm/tutorial-ilm-modify-default-warm-phase-rollover.png["Modify to add warm phase"]
.. Set one of the following options to control when the index moves to the warm phase:
*** Provide a value for *Timing for warm phase*. Setting this to *15* keeps the
indices on hot nodes for a range of 15-45 days, depending on when the initial
rollover occurred.
*** Enable *Move to warm phase on rollover*. The index might move to the warm phase
more quickly than intended if it reaches the *Maximum index size* before the
the *Maximum age*.
.. In the *Select a node attribute to control shard allocation* dropdown, select
*data:warm(2)* to migrate shards to warm data nodes.
.. Change *Number of replicas* to *1*.
.. Enable *Force merge data* and set *Number of segments* to *1*.
NOTE: When rollover is enabled in the hot phase, action timing in the other phases
is based on the rollover date.
--
. Activate the delete phase and set *Timing for delete phase* to *90* days.
+
[role="screenshot"]
image::images/ilm/tutorial-ilm-delete-rollover.png["Add a delete phase"]
[discrete]
==== Create a custom policy
If meeting a specific retention time period is most important, you can create a
custom policy. For this option, you use {filebeat} daily indices without
rollover.
To create a custom policy:
. Go to Management and select *Index Lifecycle Policies*.
. Click *Create policy*.
. Activate the warm phase and configure it as follows:
+
--
**Timing for warm phase**: 30 days from index creation
**Node attribute**: `data:warm`
**Number of replicas**: 1
**Force merge data**: enable
**Number of segments**: 1
[role="screenshot"]
image::images/ilm/tutorial-ilm-custom-policy.png["Modify the custom policy to add a warm phase"]
--
. Activate the delete phase and set the timing to 90 days.
+
[role="screenshot"]
image::images/ilm/tutorial-ilm-delete-phase-creation.png["Delete phase"]
To configure the index to use the new policy:
. Go to Management and select *Index Lifecycle Policies*.
. Find your {ilm-init} policy and click its *Actions* link.
. Choose *Add policy to index template*.
. Select your {filebeat} index template name from the *Index template* list. For example, `filebeat-7.5.x`.
. Click *Add Policy* to save the changes.
+
NOTE: If you initially used the default {filebeat} {ilm-init} policy, you will
see a notice that the template already has a policy associated with it. Confirm
that you want to overwrite that configuration.
When you change the policy associated with the index template, the active
index will continue to use the policy it was associated with at index creation
unless you manually update it. The next new index will use the updated policy.
For more reasons that your {ilm-init} policy changes might be delayed, see
<<update-lifecycle-policy, Update Lifecycle Policy>>.

View File

@ -9,6 +9,7 @@
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**:
@ -39,9 +40,9 @@ 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
. Move the old index into the warm phase, 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
. After 7 days, move the index into the cold phase and move it to less expensive
hardware.
. Delete the index once the required 30 day retention period is reached.

View File

@ -7,9 +7,6 @@
<titleabbrev>Automate rollover</titleabbrev>
++++
This tutorial demonstrates how to use {ilm}
({ilm-init}) to manage indices that contain time-series data.
When you continuously index timestamped documents into {es},
you typically use a <<data-streams, data stream>> so you can periodically roll over to a
new index.
@ -51,9 +48,6 @@ A lifecycle policy specifies the phases in the index lifecycle
and the actions to perform in each phase. A lifecycle can have up to four phases:
`hot`, `warm`, `cold`, and `delete`.
You can define and manage policies through {kib} Management or with the
<<ilm-put-lifecycle, put policy>> API.
For example, you might define a `timeseries_policy` that has two phases:
* A `hot` phase that defines a rollover action to specify that an index rolls over when it
@ -61,8 +55,16 @@ reaches either a `max_size` of 50 gigabytes or a `max_age` of 30 days.
* A `delete` phase that sets `min_age` to remove the index 90 days after rollover.
Note that this value is relative to the rollover time, not the index creation time.
The underlying put policy request looks like this:
You can create the policy through {kib} Management or with the
<<ilm-put-lifecycle, put policy>> API.
To create the policy from {kib}, go to Management and click **Index Lifecycle Policies**.
[role="screenshot"]
image:images/ilm/create-policy.png[]
.API example
[%collapsible]
====
[source,console]
------------------------
PUT _ilm/policy/timeseries_policy
@ -91,10 +93,7 @@ PUT _ilm/policy/timeseries_policy
<2> Trigger the `rollover` action when either of the conditions are met.
<3> Move the index into the `delete` phase 90 days after rollover.
<4> Trigger the `delete` action when the index enters the delete phase.
You can also invoke this API directly to add lifecycle policies.
For the complete list of actions that {ilm} can perform, see <<ilm-actions>>.
====
[discrete]
[[ilm-gs-apply-policy]]
@ -114,8 +113,9 @@ You can use the {kib} Create template wizard to add the template.
This wizard invokes the put _index_template API to create the <<indices-templates,index template>>
with the options you specify.
The underlying request looks like this:
.API example
[%collapsible]
====
[source,console]
-----------------------
PUT _index_template/timeseries_template
@ -148,8 +148,7 @@ in all documents indexed into the `timeseries` data stream.
<3> The name of the {ilm-init} policy used to manage the data stream.
<4> A <<date,`date`>> or <<date_nanos,`date_nanos`>> field mapping for the
timestamp field specified in the `timestamp_field` property
You can also invoke this API directly to add templates.
====
[discrete]
[[ilm-gs-create-the-data-stream]]
@ -318,9 +317,13 @@ that match the index pattern.
when the rollover action is triggered for an index.
You can use the {kib} Create template wizard to add the template.
This wizard invokes the put template API to create the template with the options you specify.
To access the wizard, go to Management, click **Index Management**,
and select the **Index Templates** view.
The underlying request looks like this:
[role="screenshot"]
image:images/ilm/create-template-wizard.png[]
The create template request for the example template looks like this:
[source,console]
-----------------------
@ -342,9 +345,6 @@ PUT _template/timeseries_template
<3> The name of the alias used to reference these indices.
Required for policies that use the rollover action.
You can also invoke this API directly to add templates.
//////////////////////////
[source,console]

View File

@ -68,7 +68,7 @@ but a combined index needs to be retained until you are ready to delete the new
. Reduce the {ilm-init} poll interval to ensure that the index doesn't
grow too large while waiting for the rollover check.
By default, {ilm-init} checks rollover conditions every 10 minutes.
By default, {ilm-init} checks to see what actions need to be taken every 10 minutes.
+
--
[source,console]

View File

@ -5,17 +5,20 @@
[partintro]
--
You can configure {ilm} ({ilm-init}) policies to automatically manage indices according to
your performance, resiliency, and retention requirements.
You can configure {ilm} ({ilm-init}) policies to automatically manage indices
according to your performance, resiliency, and retention requirements.
For example, you could use {ilm-init} to:
* Spin up a new index when an index reaches a certain size or number of documents
* Create a new index each day, week, or month and archive previous ones
* Delete stale indices to enforce data retention standards
You can create and manage index lifecycle policies through {kib} Management or the {ilm-init} APIs.
When you enable {ilm} for {beats} or the {ls} {es} output plugin,
{ilm-init} is configured automatically.
You can modify the default policies through {kib} Management or the {ilm-init} APIs.
default policies are configured automatically.
[role="screenshot"]
image:images/ilm/index-lifecycle-policies.png[]
[TIP]
To automatically back up your indices and manage snapshots,
@ -24,13 +27,15 @@ use <<getting-started-snapshot-lifecycle-management,snapshot lifecycle policies>
* <<overview-index-lifecycle-management>>
* <<ilm-concepts>>
* <<getting-started-index-lifecycle-management>>
* <<ilm-actions>>
* <<example-using-index-lifecycle-policy>>
* <<set-up-lifecycle-policy>>
* <<index-lifecycle-error-handling>>
* <<start-stop-ilm>>
* <<ilm-with-existing-indices>>
* <<skipping-rollover>>
* <<index-lifecycle-and-snapshots>>
* <<index-lifecycle-management-api>>
* <<ilm-actions>>
--
include::ilm-overview.asciidoc[]
@ -39,6 +44,8 @@ include::ilm-concepts.asciidoc[]
include::ilm-tutorial.asciidoc[]
include::example-index-lifecycle-policy.asciidoc[leveloffset=-1]
include::ilm-actions.asciidoc[]
include::set-up-lifecycle-policy.asciidoc[]

View File

@ -10,11 +10,13 @@ To configure a lifecycle policy for <<index-rollover, rolling indices>>,
you create the policy and add it to the <<indices-templates, index template>>.
To use a policy to manage an index that doesn't roll over,
you can specify a lifecycle policy when you create it.
you can specify a lifecycle policy when you create the index,
or apply a policy directly to an existing index.
{ilm-init} policies are stored in the global cluster state and can be included in snapshots
by setting `include_global_state` to `true` when you <<snapshots-take-snapshot, take the snapshot>>.
When the snapshot is restored, all of the policies in the global state are restored and any local policies with the same names are overwritten.
When the snapshot is restored, all of the policies in the global state are restored and
any local policies with the same names are overwritten.
IMPORTANT: When you enable {ilm} for {beats} or the {ls} {es} output plugin,
the necessary policies and configuration changes are applied automatically.
@ -25,12 +27,19 @@ bootstrap an initial index.
[[ilm-create-policy]]
=== Create lifecycle policy
You use the <<ilm-put-lifecycle,create policy API>> to define a new lifecycle policy.
For example, the following request creates `my_policy`, a
policy that defines a hot and and delete phase.
When the index reaches 25GB, it rolls over directly to the delete phase.
The index is deleted 30 days after rollover.
To create lifecycle policies through {kib} Management
go to Management and click **Index Lifecycle Policies**.
[role="screenshot"]
image:images/ilm/create-policy.png[]
You specify the lifecycle phases for the policy and the actions to perform in each phase.
The <<ilm-put-lifecycle, put policy>> API is invoked to add the policy to the {es} cluster.
.API example
[%collapsible]
====
[source,console]
------------------------
PUT _ilm/policy/my_policy
@ -57,6 +66,7 @@ PUT _ilm/policy/my_policy
<1> Roll over the index when it reaches 25GB in size
<2> Delete the index 30 days after rollover
====
[discrete]
[[apply-policy-template]]
@ -64,11 +74,19 @@ PUT _ilm/policy/my_policy
To use a policy that triggers the rollover action,
you need to configure the policy in the index template used to create each new index.
You specify the name of the policy and the alias used to reference the rolling indices.
In addition to specifying the name of the policy in the `index.lifecycle.name` setting,
you specify a `index.lifecycle.rollover_alias` for referencing
the indices managed by this policy.
To use the Create template wizard to create a template from {kib} Management,
go to Management, click **Index Management** and select the **Index Templates** view.
[role="screenshot"]
image:images/ilm/create-template-wizard.png[]
The wizard invokes the <<indices-put-template,put template API>> to add templates to a cluster.
.API example
[%collapsible]
====
[source,console]
-----------------------
PUT _template/my_template
@ -86,7 +104,7 @@ PUT _template/my_template
<1> Use this template for all new indices whose names begin with `test-`
<2> Apply `my_policy` to new indices created with this template
<3> Define an index alias for referencing indices managed by `my_policy`
====
//////////////////////////
[source,console]
@ -101,8 +119,14 @@ DELETE /_template/my_template
[[create-initial-index]]
==== Create an initial managed index
You need to manually create the first index managed by a policy that uses the rollover action
and designate it as the write index.
When you set up policies for your own rolling indices, you need to manually create the first index
managed by a policy and designate it as the write index.
IMPORTANT: When you enable {ilm} for {beats} or the {ls} {es} output plugin,
the necessary policies and configuration changes are applied automatically.
You can modify the default policies, but you do not need to explicitly configure a policy or
bootstrap an initial index.
The name of the index must match the pattern defined in the index template and end with a number.
This number is incremented to generate the name of indices created by the rollover action.
@ -133,10 +157,20 @@ index exceeds 25GB.
[[apply-policy-manually]]
=== Apply lifecycle policy manually
When you create an index, you can apply a lifecycle policy
by specifying the `index.lifecycle.name` setting.
This causes {ilm-init} to immediately start managing the index.
You can specify a policy when you create an index or
apply a policy to an existing index through {kib} Management or
the <<indices-update-settings, update settings API>>.
When you apply a policy, {ilm-init} immediately starts managing the index.
IMPORTANT: Do not manually apply a policy that uses the rollover action.
Policies that use rollover must be applied by the <<apply-policy-template, index template>>.
Otherwise, the policy is not carried forward when the rollover action creates a new index.
The `index.lifecycle.name` setting specifies an index's policy.
.API example
[%collapsible]
====
[source,console]
-----------------------
PUT test-index
@ -144,14 +178,12 @@ PUT test-index
"settings": {
"number_of_shards": 1,
"number_of_replicas": 1,
"index.lifecycle.name": "my_policy"
"index.lifecycle.name": "my_policy" <1>
}
}
-----------------------
IMPORTANT: Do not manually apply a policy that uses the rollover action.
Policies that use rollover must be applied by the <<apply-policy-template, index template>>.
Otherwise, the policy is not carried forward when the rollover action creates a new index.
<1> Sets the lifecycle policy for the index.
====
[discrete]
[[apply-policy-multiple]]

Binary file not shown.

After

Width:  |  Height:  |  Size: 145 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 187 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 90 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 471 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 69 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 121 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 247 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 444 KiB

View File

@ -7,7 +7,6 @@
:xes-repo-dir: {elasticsearch-root}/x-pack/docs/{lang}
:es-repo-dir: {elasticsearch-root}/docs/reference
include::../Versions.asciidoc[]
include::intro.asciidoc[]