Data stream lifecycle settings in Elasticsearchedit

This functionality is in technical preview and may be changed or removed in a future release. Elastic will apply best effort to fix any issues, but features in technical preview are not subject to the support SLA of official GA features.

These are the settings available for configuring data stream lifecycle.

Cluster level settingsedit

data_streams.lifecycle.poll_interval
(Dynamic, time unit value) How often Elasticsearch checks what is the next action for all data streams with a built-in lifecycle. Defaults to 5m.
cluster.lifecycle.default.rollover

(Dynamic, string) This property accepts a key value pair formatted string and configures the conditions that would trigger a data stream to rollover when it has lifecycle configured. This property is an implementation detail and subject to change. Currently, it defaults to max_age=auto,max_primary_shard_size=50gb,min_docs=1,max_primary_shard_docs=200000000, this means that your data stream will rollover if any of the following conditions are met:

  • Either any primary shard reaches the size of 50GB,
  • or any primary shard contains 200.000.000 documents
  • or the index reaches a certain age which depends on the retention time of your data stream,
  • and has at least one document.

Index level settingsedit

The following index-level settings are typically configured on the backing indices of a data stream.

index.lifecycle.prefer_ilm
(Dynamic, boolean) This setting determines which feature is managing the backing index of a data stream if, and only if, the backing index has an index lifecycle management (ILM) policy and the data stream has also a built-in lifecycle. When true this index is managed by ILM, when false the backing index is managed by the data stream lifecycle. Defaults to true.
index.lifecycle.origination_date
(Dynamic, long) If specified, this is the timestamp used to calculate the backing index generation age after this backing index has been rolled over. The generation age is used to determine data retention, consequently, you can use this setting if you create a backing index that contains older data and want to ensure that the retention period or other parts of the lifecycle will be applied based on the data’s original timestamp and not the timestamp they got indexed. Specified as a Unix epoch value in milliseconds.