With index lifecycle management (ILM), you can create policies that perform actions automatically on indices as they age and grow. ILM policies help you to manage performance, resilience, and retention of your data during its lifecycle. This tutorial shows you how to use Kibana’s Index Lifecycle Policies to modify and create ILM policies. You can learn more about all of the actions, benefits, and lifecycle phases in the ILM overview.
You’re tasked with sending syslog files to an Elasticsearch 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:
- Delete logs after 90 days
To complete this tutorial, you’ll need:
An Elasticsearch cluster with hot and warm nodes configured for shard allocation awareness. If you’re using Elasticsearch Service, choose the hot-warm architecture deployment template.
For a self-managed cluster, add node attributes as described for shard allocation filtering to label data nodes as hot or warm. This step is required to migrate shards between nodes configured with specific hardware for the hot or warm phases.
For example, you can set this in your
elasticsearch.ymlfor each data node:
A server with Filebeat installed and configured to send logs to the
elasticsearchoutput as described in Getting Started with Filebeat.
View the Filebeat ILM policyedit
Filebeat includes a default ILM policy that enables rollover. ILM
is enabled automatically if you’re using the default
filebeat.yml and index template.
To view the default policy in Kibana, open the menu, go to * Stack Management > Elasticsearch > Index Lifecycle Policies*, search for filebeat, and choose the filebeat-version policy.
This policy initiates the rollover action when the index size reaches 50GB or becomes 30 days old.
Modify the policyedit
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.
Set either 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.
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.
Create a custom policyedit
If meeting a specific retention time period is most important, you can create a custom policy. For this option, you will use Filebeat daily indices without rollover.
- To create a custom policy, open the menu, go to Stack Management > Elasticsearch > Index Lifecycle Policies, then click Create policy.
Activate the warm phase and configure it as follows:
Timing for warm phase
30 days from index creation
Number of replicas
Force merge data
Number of segments
Activate the delete phase and set the timing.
Timing for delete phase
To configure the index to use the new policy, open the menu, then go to Stack Management > Elasticsearch > Index Lifecycle Policies.
- Find your ILM policy.
- Click the Actions link next to your policy name.
- Choose Add policy to index template.
Select your Filebeat index template name from the Index template list. For example,
Click Add Policy to save the changes.
If you initially used the default Filebeat ILM 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 policy changes might be delayed, see Update Lifecycle Policy.