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>>.
|
|
|
|
|
|
|
|
|
|
`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.
|
|
|
|
|
|
|
|
|
|
`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
|
|
|
|
|
information about rollover, see <<using-policies-rollover>>.
|
2019-08-20 12:58:57 -04:00
|
|
|
|
2019-09-25 16:44:16 -04:00
|
|
|
`index.lifecycle.parse_origination_date`::
|
2020-05-08 17:22:27 -04:00
|
|
|
(<<indices-update-settings,Dynamic>>, boolean)
|
2019-09-25 16:44:16 -04:00
|
|
|
When configured to `true` the origination date will be parsed from the index
|
|
|
|
|
name. The index format 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 eg.
|
|
|
|
|
`logs-2016.10.31-000002`). If the index name doesn't match the pattern
|
|
|
|
|
the index creation will fail.
|
|
|
|
|
|
2019-09-16 03:50:28 -04:00
|
|
|
`index.lifecycle.origination_date`::
|
2020-05-08 17:22:27 -04:00
|
|
|
(<<indices-update-settings,Dynamic>>, long)
|
2019-09-16 03:50:28 -04:00
|
|
|
The timestamp that will be used to calculate the index age for its phase
|
|
|
|
|
transitions. This allows the users to create an index containing old data and
|
2020-05-08 17:22:27 -04:00
|
|
|
use the original creation date of the old data to calculate the index age.
|
|
|
|
|
Must be a long (Unix epoch) value.
|
