2018-10-26 15:19:52 -04:00
|
|
|
[role="xpack"]
|
2018-11-14 16:58:08 -05:00
|
|
|
[testenv="basic"]
|
2018-08-13 16:15:15 -04:00
|
|
|
[[getting-started-index-lifecycle-management]]
|
2020-04-28 19:38:01 -04:00
|
|
|
== Tutorial: Automate rollover with {ilm-init}
|
2020-02-04 19:45:18 -05:00
|
|
|
|
|
|
|
++++
|
|
|
|
<titleabbrev>Automate rollover</titleabbrev>
|
|
|
|
++++
|
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
This tutorial demonstrates how to use {ilm}
|
|
|
|
({ilm-init}) to manage indices that contain time-series data.
|
2018-08-13 16:15:15 -04:00
|
|
|
|
2020-04-01 10:05:20 -04:00
|
|
|
When you continuously index timestamped documents into {es} using
|
|
|
|
Filebeat, Logstash, or some other mechanism,
|
2020-02-04 19:45:18 -05:00
|
|
|
you typically use an index alias so you can periodically roll over to a new index.
|
|
|
|
This enables you to implement a hot-warm-cold architecture to meet your performance
|
|
|
|
requirements for your newest data, control costs over time, enforce retention policies,
|
|
|
|
and still get the most out of your data.
|
2018-08-13 16:15:15 -04:00
|
|
|
|
2020-02-04 19:45:18 -05:00
|
|
|
To automate rollover and management of time-series indices with {ilm-init}, you:
|
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
. <<ilm-gs-create-policy, Create a lifecycle policy>> that defines the appropriate
|
|
|
|
phases and actions.
|
2020-02-04 19:45:18 -05:00
|
|
|
. <<ilm-gs-apply-policy, Create an index template>> to apply the policy to each new index.
|
|
|
|
. <<ilm-gs-bootstrap, Bootstrap an index>> as the initial write index.
|
2020-04-28 19:38:01 -04:00
|
|
|
. <<ilm-gs-check-progress, Verify indices are moving through the lifecycle phases>>
|
|
|
|
as expected.
|
|
|
|
|
|
|
|
For an introduction to rolling indices, see <<index-rollover>>.
|
|
|
|
|
|
|
|
NOTE: {filebeat} includes a default {ilm-init} policy that initiates the rollover action when
|
|
|
|
the index size reaches 50GB or becomes 30 days old.
|
|
|
|
You can use this policy as a starting point, or replace it with a custom policy.
|
2020-05-08 13:22:39 -04:00
|
|
|
See {kibana-ref}/example-using-index-lifecycle-policy.html[Use {ilm-init} to manage Filebeat time-based indices].
|
2020-04-28 19:38:01 -04:00
|
|
|
|
2018-08-13 16:15:15 -04:00
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
[discrete]
|
2019-04-05 19:38:31 -04:00
|
|
|
[[ilm-gs-create-policy]]
|
2020-02-04 19:45:18 -05:00
|
|
|
=== Create a lifecycle policy
|
|
|
|
|
|
|
|
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:
|
2020-04-28 19:38:01 -04:00
|
|
|
`hot`, `warm`, `cold`, and `delete`.
|
2018-08-13 16:15:15 -04:00
|
|
|
|
2020-05-08 17:22:27 -04:00
|
|
|
You can define and manage policies through {kib} Management or with the
|
|
|
|
<<ilm-put-lifecycle, put policy>> API.
|
2020-04-01 10:05:20 -04:00
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
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
|
2020-02-04 19:45:18 -05:00
|
|
|
reaches either a `max_size` of 50 gigabytes or a `max_age` of 30 days.
|
2020-04-28 19:38:01 -04:00
|
|
|
* 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:
|
2018-08-13 16:15:15 -04:00
|
|
|
|
2019-09-09 13:38:14 -04:00
|
|
|
[source,console]
|
2018-11-14 16:58:08 -05:00
|
|
|
------------------------
|
2020-04-01 10:05:20 -04:00
|
|
|
PUT _ilm/policy/timeseries_policy
|
2018-11-14 16:58:08 -05:00
|
|
|
{
|
2020-04-01 10:05:20 -04:00
|
|
|
"policy": {
|
2018-11-14 16:58:08 -05:00
|
|
|
"phases": {
|
2020-02-04 19:45:18 -05:00
|
|
|
"hot": { <1>
|
2018-11-14 16:58:08 -05:00
|
|
|
"actions": {
|
2020-04-01 10:05:20 -04:00
|
|
|
"rollover": {
|
2020-02-04 19:45:18 -05:00
|
|
|
"max_size": "50GB", <2>
|
2018-11-14 16:58:08 -05:00
|
|
|
"max_age": "30d"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
},
|
|
|
|
"delete": {
|
2020-02-04 19:45:18 -05:00
|
|
|
"min_age": "90d", <3>
|
2018-11-14 16:58:08 -05:00
|
|
|
"actions": {
|
2020-02-04 19:45:18 -05:00
|
|
|
"delete": {} <4>
|
2018-11-14 16:58:08 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
------------------------
|
2020-04-01 10:05:20 -04:00
|
|
|
<1> The `min_age` defaults to `0ms`, so new indices enter the `hot` phase immediately.
|
2020-02-04 19:45:18 -05:00
|
|
|
<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.
|
2019-09-09 13:38:14 -04:00
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
You can also invoke this API directly to add lifecycle policies.
|
|
|
|
|
|
|
|
For the complete list of actions that {ilm} can perform, see <<ilm-actions>>.
|
2018-11-14 16:58:08 -05:00
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
[discrete]
|
2019-04-05 19:38:31 -04:00
|
|
|
[[ilm-gs-apply-policy]]
|
2020-02-04 19:45:18 -05:00
|
|
|
=== Create an index template to apply the lifecycle policy
|
2018-11-14 16:58:08 -05:00
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
To automatically apply a lifecycle policy to the new write index on rollover,
|
2020-02-04 19:45:18 -05:00
|
|
|
specify the policy in the index template used to create new indices.
|
2018-11-14 16:58:08 -05:00
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
For example, you might create a `timeseries_template` that is applied to new indices
|
|
|
|
whose names match the `timeseries-*` index pattern.
|
|
|
|
|
|
|
|
To enable automatic rollover, the template configures two {ilm-init} settings:
|
2020-02-04 19:45:18 -05:00
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
* `index.lifecycle.name` specifies the name of the lifecycle policy to apply to new indices
|
|
|
|
that match the index pattern.
|
2020-04-01 10:05:20 -04:00
|
|
|
* `index.lifecycle.rollover_alias` specifies the index alias to be rolled over
|
2020-02-04 19:45:18 -05:00
|
|
|
when the rollover action is triggered for an index.
|
2018-11-14 16:58:08 -05:00
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
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.
|
|
|
|
|
|
|
|
The underlying request looks like this:
|
|
|
|
|
2019-09-09 13:38:14 -04:00
|
|
|
[source,console]
|
2018-11-14 16:58:08 -05:00
|
|
|
-----------------------
|
2020-04-01 10:05:20 -04:00
|
|
|
PUT _template/timeseries_template
|
2018-11-14 16:58:08 -05:00
|
|
|
{
|
2020-04-01 10:05:20 -04:00
|
|
|
"index_patterns": ["timeseries-*"], <1>
|
2018-11-14 16:58:08 -05:00
|
|
|
"settings": {
|
|
|
|
"number_of_shards": 1,
|
|
|
|
"number_of_replicas": 1,
|
2020-04-01 10:05:20 -04:00
|
|
|
"index.lifecycle.name": "timeseries_policy", <2>
|
|
|
|
"index.lifecycle.rollover_alias": "timeseries" <3>
|
2018-11-14 16:58:08 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
-----------------------
|
|
|
|
// TEST[continued]
|
2019-09-09 13:38:14 -04:00
|
|
|
|
2020-04-01 10:05:20 -04:00
|
|
|
<1> Apply the template to a new index if its name starts with `timeseries-`.
|
2020-02-04 19:45:18 -05:00
|
|
|
<2> The name of the lifecycle policy to apply to each new index.
|
2020-04-01 10:05:20 -04:00
|
|
|
<3> The name of the alias used to reference these indices.
|
2020-02-04 19:45:18 -05:00
|
|
|
Required for policies that use the rollover action.
|
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
You can also invoke this API directly to add templates.
|
|
|
|
|
|
|
|
|
2020-01-28 09:36:29 -05:00
|
|
|
//////////////////////////
|
|
|
|
|
|
|
|
[source,console]
|
|
|
|
--------------------------------------------------
|
2020-04-01 10:05:20 -04:00
|
|
|
DELETE /_template/timeseries_template
|
2020-01-28 09:36:29 -05:00
|
|
|
--------------------------------------------------
|
|
|
|
// TEST[continued]
|
|
|
|
|
|
|
|
//////////////////////////
|
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
[discrete]
|
2020-02-04 19:45:18 -05:00
|
|
|
[[ilm-gs-bootstrap]]
|
|
|
|
=== Bootstrap the initial time-series index
|
2018-11-14 16:58:08 -05:00
|
|
|
|
2020-04-01 10:05:20 -04:00
|
|
|
To get things started, you need to bootstrap an initial index and
|
|
|
|
designate it as the write index for the rollover alias specified in your index template.
|
|
|
|
The name of this index must match the template's index pattern and end with a number.
|
|
|
|
On rollover, this value is incremented to generate a name for the new index.
|
2018-11-14 16:58:08 -05:00
|
|
|
|
2020-04-01 10:05:20 -04:00
|
|
|
For example, the following request creates an index called `timeseries-000001`
|
|
|
|
and makes it the write index for the `timeseries` alias.
|
2018-11-14 16:58:08 -05:00
|
|
|
|
2019-09-09 13:38:14 -04:00
|
|
|
[source,console]
|
2018-11-14 16:58:08 -05:00
|
|
|
-----------------------
|
2020-04-01 10:05:20 -04:00
|
|
|
PUT timeseries-000001
|
2018-11-14 16:58:08 -05:00
|
|
|
{
|
|
|
|
"aliases": {
|
2020-04-01 10:05:20 -04:00
|
|
|
"timeseries": {
|
2018-11-14 16:58:08 -05:00
|
|
|
"is_write_index": true
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
-----------------------
|
|
|
|
// TEST[continued]
|
|
|
|
|
2020-02-04 19:45:18 -05:00
|
|
|
When the rollover conditions are met, the `rollover` action:
|
|
|
|
|
2020-04-01 10:05:20 -04:00
|
|
|
* Creates a new index called `timeseries-000002`.
|
|
|
|
This matches the `timeseries-*` pattern, so the settings from `timeseries_template` are applied to the new index.
|
2020-02-04 19:45:18 -05:00
|
|
|
* Designates the new index as the write index and makes the bootstrap index read-only.
|
|
|
|
|
2020-04-01 10:05:20 -04:00
|
|
|
This process repeats each time rollover conditions are met.
|
|
|
|
You can search across all of the indices managed by the `timeseries_policy` with the `timeseries` alias.
|
|
|
|
Write operations are routed to the current write index.
|
2020-02-04 19:45:18 -05:00
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
[discrete]
|
2019-04-05 19:38:31 -04:00
|
|
|
[[ilm-gs-check-progress]]
|
2020-04-28 19:38:01 -04:00
|
|
|
=== Check lifecycle progress
|
2018-11-14 16:58:08 -05:00
|
|
|
|
2020-04-01 10:05:20 -04:00
|
|
|
To get status information for managed indices, you use the {ilm-init} explain API.
|
2020-02-04 19:45:18 -05:00
|
|
|
This lets you find out things like:
|
|
|
|
|
|
|
|
* What phase an index is in and when it entered that phase.
|
|
|
|
* The current action and what step is being performed.
|
|
|
|
* If any errors have occurred or progress is blocked.
|
2018-11-14 16:58:08 -05:00
|
|
|
|
2020-04-01 10:05:20 -04:00
|
|
|
For example, the following request gets information about the `timeseries` indices:
|
2018-11-14 16:58:08 -05:00
|
|
|
|
2019-09-09 13:38:14 -04:00
|
|
|
[source,console]
|
2018-11-14 16:58:08 -05:00
|
|
|
--------------------------------------------------
|
2020-04-01 10:05:20 -04:00
|
|
|
GET timeseries-*/_ilm/explain
|
2018-11-14 16:58:08 -05:00
|
|
|
--------------------------------------------------
|
|
|
|
// TEST[continued]
|
|
|
|
|
2020-02-04 19:45:18 -05:00
|
|
|
The response below shows that the bootstrap index is waiting in the `hot` phase's `rollover` action.
|
2020-04-01 10:05:20 -04:00
|
|
|
It remains in this state and {ilm-init} continues to call `attempt-rollover`
|
|
|
|
until the rollover conditions are met.
|
2018-11-14 16:58:08 -05:00
|
|
|
|
2020-04-28 19:38:01 -04:00
|
|
|
// [[36818c6d9f434d387819c30bd9addb14]]
|
2019-09-09 13:38:14 -04:00
|
|
|
[source,console-result]
|
2018-11-14 16:58:08 -05:00
|
|
|
--------------------------------------------------
|
|
|
|
{
|
|
|
|
"indices": {
|
2020-04-01 10:05:20 -04:00
|
|
|
"timeseries-000001": {
|
|
|
|
"index": "timeseries-000001",
|
|
|
|
"managed": true,
|
|
|
|
"policy": "timeseries_policy", <1>
|
2018-11-14 16:58:08 -05:00
|
|
|
"lifecycle_date_millis": 1538475653281,
|
2020-02-04 19:45:18 -05:00
|
|
|
"age": "30s", <2>
|
2020-04-01 10:05:20 -04:00
|
|
|
"phase": "hot",
|
2018-11-14 16:58:08 -05:00
|
|
|
"phase_time_millis": 1538475653317,
|
2020-04-01 10:05:20 -04:00
|
|
|
"action": "rollover",
|
2018-11-14 16:58:08 -05:00
|
|
|
"action_time_millis": 1538475653317,
|
2020-02-04 19:45:18 -05:00
|
|
|
"step": "attempt-rollover", <3>
|
2018-11-14 16:58:08 -05:00
|
|
|
"step_time_millis": 1538475653317,
|
|
|
|
"phase_execution": {
|
2020-04-01 10:05:20 -04:00
|
|
|
"policy": "timeseries_policy",
|
2020-02-04 19:45:18 -05:00
|
|
|
"phase_definition": { <4>
|
2018-11-14 16:58:08 -05:00
|
|
|
"min_age": "0ms",
|
|
|
|
"actions": {
|
|
|
|
"rollover": {
|
|
|
|
"max_size": "50gb",
|
|
|
|
"max_age": "30d"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
},
|
2020-04-01 10:05:20 -04:00
|
|
|
"version": 1,
|
2018-11-14 16:58:08 -05:00
|
|
|
"modified_date_in_millis": 1539609701576
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
2018-11-14 19:45:06 -05:00
|
|
|
// TESTRESPONSE[skip:no way to know if we will get this response immediately]
|
2019-09-09 13:38:14 -04:00
|
|
|
|
2020-04-01 10:05:20 -04:00
|
|
|
<1> The policy used to manage the index
|
2020-02-04 19:45:18 -05:00
|
|
|
<2> The age of the index
|
|
|
|
<3> The step {ilm-init} is performing on the index
|
|
|
|
<4> The definition of the current phase (the `hot` phase)
|