2019-04-05 19:38:31 -04:00
|
|
|
[role="xpack"]
|
|
|
|
|
[[ilm-settings]]
|
2020-05-08 17:22:27 -04:00
|
|
|
=== {ilm-cap} settings in {es}
|
|
|
|
|
[subs="attributes"]
|
|
|
|
|
++++
|
|
|
|
|
<titleabbrev>{ilm-cap} settings</titleabbrev>
|
|
|
|
|
++++
|
2019-04-05 19:38:31 -04:00
|
|
|
|
2020-05-08 17:22:27 -04:00
|
|
|
These are the settings available for configuring <<index-lifecycle-management, {ilm}>> ({ilm-init}).
|
2019-09-17 19:39:41 -04:00
|
|
|
|
|
|
|
|
==== Cluster level settings
|
|
|
|
|
|
|
|
|
|
`xpack.ilm.enabled`::
|
2020-05-08 17:22:27 -04:00
|
|
|
(boolean)
|
2020-04-30 09:50:18 -04:00
|
|
|
deprecated:[7.8.0,Basic License features are always enabled] +
|
|
|
|
|
This deprecated setting has no effect and will be removed in Elasticsearch 8.0.
|
2019-09-17 19:39:41 -04:00
|
|
|
|
2020-01-30 17:27:44 -05:00
|
|
|
`indices.lifecycle.history_index_enabled`::
|
2020-05-08 17:22:27 -04:00
|
|
|
(boolean)
|
[7.x] Add ILM histore store index (#50287) (#50345)
* Add ILM histore store index (#50287)
* Add ILM histore store index
This commit adds an ILM history store that tracks the lifecycle
execution state as an index progresses through its ILM policy. ILM
history documents store output similar to what the ILM explain API
returns.
An example document with ALL fields (not all documents will have all
fields) would look like:
```json
{
"@timestamp": 1203012389,
"policy": "my-ilm-policy",
"index": "index-2019.1.1-000023",
"index_age":123120,
"success": true,
"state": {
"phase": "warm",
"action": "allocate",
"step": "ERROR",
"failed_step": "update-settings",
"is_auto-retryable_error": true,
"creation_date": 12389012039,
"phase_time": 12908389120,
"action_time": 1283901209,
"step_time": 123904107140,
"phase_definition": "{\"policy\":\"ilm-history-ilm-policy\",\"phase_definition\":{\"min_age\":\"0ms\",\"actions\":{\"rollover\":{\"max_size\":\"50gb\",\"max_age\":\"30d\"}}},\"version\":1,\"modified_date_in_millis\":1576517253463}",
"step_info": "{... etc step info here as json ...}"
},
"error_details": "java.lang.RuntimeException: etc\n\tcaused by:etc etc etc full stacktrace"
}
```
These documents go into the `ilm-history-1-00000N` index to provide an
audit trail of the operations ILM has performed.
This history storage is enabled by default but can be disabled by setting
`index.lifecycle.history_index_enabled` to `false.`
Resolves #49180
* Make ILMHistoryStore.putAsync truly async (#50403)
This moves the `putAsync` method in `ILMHistoryStore` never to block.
Previously due to the way that the `BulkProcessor` works, it was possible
for `BulkProcessor#add` to block executing a bulk request. This was bad
as we may be adding things to the history store in cluster state update
threads.
This also moves the index creation to be done prior to the bulk request
execution, rather than being checked every time an operation was added
to the queue. This lessens the chance of the index being created, then
deleted (by some external force), and then recreated via a bulk indexing
request.
Resolves #50353
2019-12-20 14:33:36 -05:00
|
|
|
Whether ILM's history index is enabled. If enabled, ILM will record the
|
|
|
|
|
history of actions taken as part of ILM policies to the `ilm-history-*`
|
|
|
|
|
indices. Defaults to `true`.
|
|
|
|
|
|
2020-05-08 17:22:27 -04:00
|
|
|
`indices.lifecycle.poll_interval`::
|
|
|
|
|
(<<cluster-update-settings,Dynamic>>, <<time-units, time unit value>>)
|
|
|
|
|
How often {ilm} checks for indices that meet policy criteria. Defaults to `10m`.
|
|
|
|
|
|
2019-09-17 19:39:41 -04:00
|
|
|
==== Index level settings
|
2019-04-05 19:38:31 -04:00
|
|
|
These index-level {ilm-init} settings are typically configured through index
|
|
|
|
|
templates. For more information, see <<ilm-gs-create-policy>>.
|
|
|
|
|
|
2020-06-05 21:55:51 -04:00
|
|
|
`index.lifecycle.indexing_complete`::
|
|
|
|
|
(<<indices-update-settings,Dynamic>>, boolean)
|
|
|
|
|
Indicates whether or not the index has been rolled over.
|
|
|
|
|
Automatically set to `true` when {ilm-init} completes the rollover action.
|
|
|
|
|
You can explicitly set it to <<skipping-rollover, skip rollover>>.
|
|
|
|
|
Defaults to `false`.
|
|
|
|
|
|
2019-04-05 19:38:31 -04:00
|
|
|
`index.lifecycle.name`::
|
2020-05-08 17:22:27 -04:00
|
|
|
(<<indices-update-settings, Dynamic>>, string)
|
2019-04-05 19:38:31 -04:00
|
|
|
The name of the policy to use to manage the index.
|
|
|
|
|
|
2020-06-05 21:55:51 -04:00
|
|
|
[[index-lifecycle-origination-date]]
|
|
|
|
|
`index.lifecycle.origination_date`::
|
|
|
|
|
(<<indices-update-settings,Dynamic>>, long)
|
|
|
|
|
If specified, this is the timestamp used to calculate the index age for its phase transitions.
|
|
|
|
|
Use this setting if you create a new index that contains old data and
|
|
|
|
|
want to use the original creation date to calculate the index age.
|
|
|
|
|
Specified as a Unix epoch value.
|
|
|
|
|
|
|
|
|
|
`index.lifecycle.parse_origination_date`::
|
|
|
|
|
(<<indices-update-settings,Dynamic>>, boolean)
|
|
|
|
|
Set to `true` to parse the origination date from the index name.
|
|
|
|
|
This origination date is used to calculate the index age for its phase transitions.
|
|
|
|
|
The index name must match the pattern `^.*-{date_format}-\\d+`,
|
|
|
|
|
where the `date_format` is `yyyy.MM.dd` and the trailing digits are optional.
|
|
|
|
|
An index that was rolled over would normally match the full format,
|
|
|
|
|
for example `logs-2016.10.31-000002`).
|
|
|
|
|
If the index name doesn't match the pattern, index creation fails.
|
|
|
|
|
|
2019-04-05 19:38:31 -04:00
|
|
|
`index.lifecycle.rollover_alias`::
|
2020-05-08 17:22:27 -04:00
|
|
|
(<<indices-update-settings,Dynamic>>, string)
|
2019-04-05 19:38:31 -04:00
|
|
|
The index alias to update when the index rolls over. Specify when using a
|
|
|
|
|
policy that contains a rollover action. When the index rolls over, the alias is
|
|
|
|
|
updated to reflect that the index is no longer the write index. For more
|
2020-06-05 21:55:51 -04:00
|
|
|
information about rolling indices, see <<index-rollover, Rollover>>.
|
