1. 概念介绍
1.1 索引生命周期
1.1.1 Index 5个生命周期阶段
Hot：Index 被频繁地更新和检索
Warm：Index 不再更新，但仍可频繁检索
Cold：Index 不再更新，不被频繁检索。信息仍然可被搜索，但检索速度很慢
Frozen：Index 不再更新，检索也几乎没有。信息仍然可被搜索，但检索速度会极慢
Delete：Index 不再需要，并且可以安全删除
Index 生命周期策略定义了：
适用的阶段
各阶段执行的动作
阶段间转换的时机
生命周期策略应用方式：
手动应用：在 Index 创建时可以手动应用生命周期策略
自动应用：或者在 Index 模板中生命周期策略，可以在周期（时间序列）性创建 Index 时将生命周期应用到新建的 Index 上，这种情况下，上次手动应用的生命周期策略不会作用到新建的 Index 上
1.1.2 阶段间切换
ILM 根据 Index 的年龄切换 Index 的生命周期
Minimum age：
每个生命周期阶段可以设置一个最小年龄，Index 的生命周期切换到下一个生命周期的条件是，当前生命周期阶段的所有动作（actions）完成，并且当前的生命周期年龄大于最小年龄设置。
下一个生命周期的最小年龄必须不小于（>=）上一个设置的最小年龄，例如 warm 阶段的 minimum age 设置为 10 天，则下一阶段 cold 阶段的 minimum age 默认相等，或可以设置 >= 10 天
Minimum age 默认为0，这种情况下，ILM 一旦完成了当前阶段的动作，就会切换到下一个阶段
当 Index 未分配 shard 并且集群健康状态是 yellow，Index 仍然会按照生命周期管理策略切换到下一个阶段。然而，由于 ES 只能在 green 状态的集群中执行指定的 clean up 任务，因此这种情况可能会产生意外的副作用
1.1.3 阶段运行
ILM 控制一个阶段中动作的执行顺序，以及每个动作中执行必要 Index 操作所需执行的步骤。
当 Index 进入一个阶段， ILM 会缓存 index metadata 中的阶段定义。如果安全的应用了阶段，ILM 更新缓存中的阶段定义，否则阶段运行继续当前的缓存定义
ILM 会周期性的运行，来检查 index 是否符合策略标准，并执行需要的步骤。为了避免竞争条件，ILM 可能运行不仅1次，从而执行一个动作的所有需要的步骤。例如，当 ILM 判定 Index 遇到了翻滚标准（rollover），就开始执行翻滚动作的步骤。如果遇到一个不安全的状况，将会停止运行，下次 ILM 运行时， ILM 会继续执行未执行的步骤。这就意味着实际的动作时间要比策略设置的间隔时间长
1.1.4 阶段动作
ILM 各阶段支持的动作如下
-
Hot
-
Warm
-
Cold
-
Frozen
-
Delete
Set Priority
在 index 进入一个阶段时，首先设置该 Index 的优先级。当节点重新启动后，优先恢复优先级高的 index
选项：priority，优先级，大于0的整数，设置null移除优先级
举例：
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"set_priority" : {
"priority": 50
} } } } } }
Unfollow
将跨集群复制（CCR）follower index 转变成正常 index。这个动作实现了 shrink、rollover 和 searchable snapshot 动作在 follower index 上安全执行。You can also use unfollow directly when moving follower indices through the lifecycle. 在非 follower 的 index 上该动作无效，阶段运行直接转到下一个动作。
Rollover
在已有 Index 触发一个或多个 rollover 条件时，将目标滚动到一个新的 index 中
Rollover 目标可以是 data stream 或 index alias。当目标是 data stream，新的 index 将成为 data stream 的写 index，并且其迭代版本增加
滚动一个 index alias 时，alias 及其 写 index 必须符合以下条件：
Index name 必须匹配模式
^.*-\d+$，例如（my-index-000001）index.lifecycle.rollover_alias必须配置成要滚动的别名index 必须是别名的写 index
例如
PUT my-index-000001
{
"settings": {
"index.lifecycle.name": "my_policy",
"index.lifecycle.rollover_alias": "my_data"
},
"aliases": {
"my_data": {
"is_write_index": true
} } }
选项：必须指定至少一个 rollover 条件，禁止空的 rollover 动作
max_age: (Optional, time units) 从 index 创建开始算起，到达最大运行时间时触发 rollover 动作。即使 index 的 origination date 配置到指定时间（例如 index.lifecycle.parse_origination_date 或 index.lifecycle.origination_date），运行时间仍然按照 index 创建开始算起max_docs: (Optional, integer) 到达指定最大文档数后触发 rollover 动作。从最后一次刷新增加的文档数不算入文档计数，文档计数不包括副本分片的文档max_size:(Optional, byte units) 当 index 达到指定大小时触发 rollover 动作。该大小值得是所有主分片的总大小max_primary_shard_size: (Optional, byte units) 在 index 最大的主分片达到指定大小触发 rollover 动作。
举例：
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover" : {
"max_primary_shard_size": "50GB"
} } } } } }
Read only
标记 index 为只读
在 hot 阶段使用 readonly 动作，必须已配置 rollover 动作，否则 ILM 拒绝该策略
举例：
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"readonly" : { }
} } } } }
Shrink
将源 index 设置为 read-only 并将其缩减到一个有更少主分片的新 index 中。缩减后 index 名为 shrink-<random-uuid>-<original-index-name>，该动作相当于 shrink API
Shrink 动作结束后，指向源 index 的所有别名(alia）将指向新的 index。如果 ILM 在一个数据流的支持 index 上执行 shrink 动作，则在该数据流中收缩的 index 将替代源 index 。在写 index 上无法执行 shrink 动作。
在 hot 阶段使用 shrink 操作，必须已配置 rollover 动作。否则 ILM 拒绝该策略
Shrink 动作会移除 index 的 index.routing.allocation.total_shards_per_node setting配置，这意味着取消该配置限制。这将保证所有 index 的分片可以复制到一个单独节点上。该设置会一直保留到该 index 中。
选项：
number_of_shards: (Optional, integer) 收缩的分片数量。必须是源 index 分片数的一个因素。该参数与max_primary_shard_size冲突，只能设置两个值中的一个max_primary_shard_size****: (Optional, byte units****) 目标 index 最大主分片大小。用于找出目标 index 最优分片数量。该参数限制目标 index 的每个分片的存储大小。目标 index shards 计数仍然是源 index 分片的计数因素，但如果该参数设置小于源 index 单分片大小，则目标 index 的分片计数将等于源 index 分片计数
举例：
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"shrink" : {
"number_of_shards": 1
} } } } } }
计算收缩 index 的最优主分片数
下面的策略使用 max_primary_shard_size 参数来基于原索引存储大小自动计算新的收缩 index 主分片数量
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"shrink" : {
"max_primary_shard_size": "50gb"
} } } } } }
Shrink 的分片分配
在 shrink 动作期间， ILM 分配源 index 主分片到一个节点。在 shrink 动作结束后， ILM 基于分配规则重新分配收缩 Index 分片给合适的节点
以下情况可能导致这些分配步骤失败：
在 shrink 动作期间，一个节点被移除
所有节点都没有足够的磁盘空间来存放源 index 分片
在分配规则间相冲突的情况下，ES无法重新分配收缩 index
当分配步骤失败时， ILM 等待[index.lifecycle.step.wait_time_threshold](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/ilm-settings.html#index-lifecycle-step-wait-time-threshold) 配置的间隔时间，默认是12h。该等待间隔是留给集群解决以上问题的。
If the threshold period passes and ILM has not yet shrunk the index, ILM attempts to allocate the source index’s primary shards to another node. If ILM shrunk the index but could not reallocate the shrunken index’s shards during the threshold period, ILM deletes the shrunken index and re-attempts the entire shrink action.
Force merge
强制合并 index 为指定最大数量的段。该动作执行会设置 index 为只读。
在 hot 阶段使用 forcemerge 操作，必须已配置 rollover 动作。否则 ILM 拒绝该策略。
性能考量：强制合并是一项资源密集型操作。如果一次性触发太多强制合并，将会显著影响集群性能。
配置
min_age参数或设置index.lifecycle.origination_date可以避免 ILM 策略同时给多个 index 执行强制合并动作如果遇到强制合并任务队列积压，可以通过设置
thread_pool.force_merge.size集群配置来增加线程池，增加任务并行数量，该操作需要在监控集群性能的条件下缓慢的增加线程池大小，以避免级联性能影响
选项：
max_num_segments: (Required, integer) 合并后的段数量。想要充分的合并 index ，设置成1index_codec: (Optional, string) 用来压缩文档存储的 Codec。只接受best_compression值，使用 deflate 压缩算法提高压缩率但降低存储性能，如果不设置该值，则默认使用 LZ4 codec。（注意，使用 best_compression ，ILM 会在执行 force merge 前，关闭并再开启 index，期间 index 不可读写）
举例：
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"forcemerge" : {
"max_num_segments": 1
} } } } }
Searchable snapshot
给被管理的 index 拍摄快照放到配置的仓储，并挂载为 searchable snapshot。如果 index 是一个数据流的一部分，在该数据流中，挂载的 index 取代原来的 index
The searchable_snapshot action requires data tiers. The action uses the [index.routing.allocation.include._tier_preference](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/data-tier-shard-filtering.html#tier-preference-allocation-filter) setting to mount the index directly to the phase’s corresponding data tier. In the frozen phase, the action mounts a partially mounted index prefixed with partial- to the frozen tier. In other phases, the action mounts a fully mounted index prefixed with restored- to the corresponding data tier.
searchable_snapshot 动作不能同时包含在 hot 和 cold 阶段，这会导致 index 在 cold 阶段自动迁移到 cold tier 失败
该动作无法作用于写 index。To convert the index to a searchable snapshot, first manually roll over the data stream. This creates a new write index. Because the index is no longer the stream’s write index, the action can then convert it to a searchable snapshot. Using a policy that makes use of the rollover action in the hot phase will avoid this situation and the need for a manual rollover for future managed indices.
选项：
snapshot_repository: (Required, string) 用来存储 snapshot 的仓储force_merge_index: (Optional, Boolean) 强制合并被管理 index 为一个段。默认为 true。该操作会在searchable_snapshot动作所在的阶段之前的阶段执行
举例：
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"cold": {
"actions": {
"searchable_snapshot" : {
"snapshot_repository" : "backing_repo"
} } } } } }
Allocate
更新index配置，修改索引分片的宿主节点和副本分片的数量
Index 的初始分配必须手动完成或通过 index 模板完成
参考：副本和scal: Scalability and resilience， Index-level shard allocation filtering —— 控制 index 分配分片的宿主机
选项：必须指定副本的数量，或至少 include, exclude, require 选项中的一个。不支持空的分配动作
number_of_replicas：(Optional, integer) 分配给 index 的副本数量toal_shards_per_node：(Optional, integer) 单 ES 节点的最大分片数量。-1 意味着没有限制。见 total shardsinclude：(Optional, object) 将一个 index 分配给那些拥有至少一个指定自定义属性的节点exclude：(Optional, object) 将一个 index 分配给那些没有指定自定义属性的节点require：(Optional, object) 将一个 index 分配给那些有所有指定自定义属性的节点
举例1：下面的策略修改 index 的副本数为2，index 不超过200的分片将放置到任意单个节点
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"allocate" : {
"number_of_replicas" : 2,
"total_shards_per_node" : 200
} } } } } }
举例2：下面的策略将 index 分配给有 box_type 属性为 hot 或 warm 的节点
要指定节点的 box_type，需要配置节点配置中的属性，例如设置 elasticsearch.yml 文件
node.attr.box_type: hot，更多信息见 Enabling index-level shard allocation filtering.
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"allocate" : {
"include" : {
"box_type": "hot,warm"
} } } } } }
举例3：下面的策略将 index 基于多个节点属性分配给节点，box_type 和 storage
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"cold": {
"actions": {
"allocate" : {
"require" : {
"box_type": "cold",
"storage": "high"
} } } } } }
举例4：更新 index 设置每个分片有一个副本并分配到 节点属性 box_type 是 cold 的节点上
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"allocate" : {
"number_of_replicas": 1,
"require" : {
"box_type": "cold"
}
} } } } } } }
Migrate
将 index 迁移到当前阶段对应的 data tier，通过更新 index 配置 [index.routing.allocation.include._tier_preference](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/data-tier-shard-filtering.html#tier-preference-allocation-filter)。在没有 allocate 动作以及 allocate 动作没有指定 allocation 选项时，ILM 自动向 warm 和 cold 阶段注入 migrate 动作。如果 allocate 动作只修改 index 副本数量，ILM 在迁移 index 前减少副本的数量。通过明确的配置 migrate 动作，设置 enabled 选项为 false，可以避免未指定 allocation 选项的自动迁移。
不自动注入的情况：If the
coldphase defines a searchable snapshot action themigrateaction will not be injected automatically in thecoldphase because the managed index will be mounted directly on the target tier using the same _tier_preference infrastructure themigrateactions configures.
在 warm 阶段，migrate 动作设置 [index.routing.allocation.include._tier_preference](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/data-tier-shard-filtering.html#tier-preference-allocation-filter) 为data_warm,data_hot。这个配置将 index 迁移到 warm tier 中的节点上。如果 warm tier 中没有节点，则 index 回到 hot tier
在 cold 阶段，migrate 动作设置 [index.routing.allocation.include._tier_preference](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/data-tier-shard-filtering.html#tier-preference-allocation-filter) 为
data_cold,data_warm,data_hot，这个配置将 index 迁移到 cold tier 下的节点中。如果 cold tier 下没有节点，则迁移到 warm tier 下的节点，如果 warm tier 下没有节点，则迁移到 hot tier
Frozen 阶段没有 migrate 动作，该阶段使用 [index.routing.allocation.include._tier_preference](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/data-tier-shard-filtering.html#tier-preference-allocation-filter) 值为 data_frozen,data_cold,data_warm,data_hot 来挂载 searchable snapshot。
选项：
-
enabled: (Optional, Boolean) 控制 ILM 是否在当前阶段迁移 index。默认为 true
举例1：以下策略指定在 ILM 将 index 迁移到 warm 节点前，用 allocate 动作来减少副本数量
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"migrate" : {
},
"allocate": {
"number_of_replicas": 1
} } } } } }
举例2：关闭自动迁移。以下策略关闭了迁移动作，并且分配动作将 index 分配到 rack_id 属性是 one 或 two 的节点上
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"migrate" : {
"enabled": false
},
"allocate": {
"include" : {
"rack_id": "one,two"
} } } } } } }
Freeze
冷冻（api:Freezes）一个 index
在 7.14 版本中移除，因为7.7版本后，堆内存的使用情况得到了改善
Wait for snapshot
在删除index 前，等待指定的 SLM 策略被执行完毕。这保证了一个删除的 index 的 snapshot 可访问
选项：
-
policy: (Required, string) SLM 策略的名称，也是delete 动作需要等待的策略
举例
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"delete": {
"actions": {
"wait_for_snapshot" : {
"policy": "slm-policy-name"
} } } } } }
Delete
永久的移除 index
选项：
-
delete_searchable_snapshot: (Optional, Boolean) 是否删除先前阶段生成的 searchable snapshot，默认为 true，这个选项在 searchable snapshot 动作用于先前阶段的情况下有效
举例：
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"delete": {
"actions": {
"delete" : { }
} } } } }
1.2 Rollover
对于日志类或度量类(metric)具有时间序列特征的数据，推荐使用 data streams 来管理。
Data stream 需要用到 index 模板：
A name or wildcard (
*) pattern for the data stream.The data stream’s timestamp field. This field must be mapped as a
[date](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/date.html)or[date_nanos](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/date_nanos.html)field data type and must be included in every document indexed to the data stream.The mappings and settings applied to each backing index when it’s created.
Data streams 设计用于 append-only 数据，如果用例数据需要适当的更新，推荐使用 index aliases 管理时间序列数据
Index aliases 需要几个配置：
Index 模板，典型的配置例如把分片数量设置成为 hot 节点的数量
Index 别名，用于引用整个 index 集
指定单独的索引作为写 index。这时处理所有写请求的活跃 index。在每个阶段，新的索引成为写 index
自动翻滚
ILM 允许基于 index size，document count，age来自动翻滚新的 index。当 rollover 触发，新的索引创建， write alias 更新指到新的索引，并且所有随后的更新都写到新的索引中。
Tip: Rolling over to a new index based on size, document count, or age is preferable to time-based rollovers. Rolling over at an arbitrary time often results in many small indices, which can have a negative impact on performance and resource usage.
1.3 生命周期策略的更新
阶段定义通常在进入到该阶段时缓存(cache)在 index metadata 中。如果策略修改可以被安全应用， ILM 更新缓存的阶段定义，否则，阶段运行继续使用已缓存的定义。
当 index 进入到下一个阶段时，会采用更新策略的阶段定义。
2. 使用 ILM 自动实现自动翻滚（非 data stream）
使用 Data stream 是scale 和管理时间序列数据的一种简单方法，但这种形式不直接支持删除和更新请求。这时候可以使用 index alias 来管理具有时间序列数据，并且需要周期性翻滚到新 index 的 indeices 。
要使用 index alias 来利用 ILM 自动翻滚和管理时间序列 index，需要：
创建生命周期策略，定义合适的阶段和动作
创建 index 模板来应用策略到每个新的 index
引导一个 index 作为初始写index
验证 index 在生命周期各阶段如预期迁移
2.1 创建生命周期策略
创建生命周期可以通过 Kibana 或用 create or update policy API。
Kibana创建
menu -> Stack Management -> Index Lifecycle Policies，点击 Create policy
API 创建
PUT _ilm/policy/timeseries_policy
{
"policy": {
"phases": {
"hot": { //min_age默认为 0ms，所以新的索引会立刻进入 hot 阶段
"actions": {
"rollover": {
"max_primary_shard_size": "50GB", //触发条件，满足任意一个都会触发
"max_age": "30d"
}
}
},
"delete": {
"min_age": "90d", //rollover 90天后把 index 迁移到 delete 阶段
"actions": {
"delete": {} //当 index 进入 delete 阶段，触发 delete 动作
}
}
}
}
}
优化版ILM策略（可参考）
PUT _ilm/policy/hot-warm-cold-delete-60days
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": {
"max_size":"50gb",
"max_age":"30d"
},
"set_priority": {
"priority":50
}
}
},
"warm": {
"min_age":"7d",
"actions": {
"forcemerge": {
"max_num_segments":1
},
"shrink": {
"number_of_shards":1
},
"allocate": {
"require": {
"data": "warm"
}
},
"set_priority": {
"priority":25
}
}
},
"cold": {
"min_age":"30d",
"actions": {
"set_priority": {
"priority":0
},
"freeze": {},
"allocate": {
"require": {
"data": "cold"
}
}
}
},
"delete": {
"min_age":"60d",
"actions": {
"delete": {}
}
}
}
}
}
2.2 创建 index 模板来应用生命周期策略
创建生命周期策略后，可以在 index 模板中指定策略，从而在 rollover 期间创建写 index 时自动应用。
模板配置2项 ILM 设置，可以自动 rollover
index.lifecycle.name: 指定生命周期策略的名字index.lifecycle.rollover_alias: 指定 index 别名，用于 rollover 动作时滚动新的 index
使用 kibana 创建模板：Stack Management > Index Management > Index Templates tab > Create template
使用接口创建模板：
PUT _index_template/timeseries_template
{
"index_patterns": ["timeseries-*"],
"template": {
"settings": {
"number_of_shards": 1,
"number_of_replicas": 1,
"index.lifecycle.name": "timeseries_policy",
"index.lifecycle.rollover_alias": "timeseries"
}
}
}
2.3 用写 index 别名启动一个初始的时间序列 index
创建一个 index 并将其标明为写 index。 Index 名称需要匹配模板中的 index pattern，并且用一个数字结尾。在 rollover 时，该值将会为新生成的 index 自动增长。举例：
PUT timeseries-000001
{
"aliases": {
"timeseries": {
"is_write_index": true
}
}
}
当触发 rollover 动作时：
创建新的 index 名为
timeseries-000002标明新的 index 作为写 index，并标明启动 index 为只读
每次触发 rollover 动作，都会如此执行。用 timeseries 别名可以检索所有 index，写操作将路由到当前写 index
2.4 检查生命周期程序
使用 ILM explain API 可以获取受管理的 index 的状态信息。可以查看：
Index 在那个阶段，以及进入的时间
当前动作以及下一步要执行的步骤
错误信息和阻塞的程序
GET timeseries-*/_ilm/explain
3. 使用节点角色让 ILM 自动迁移 index
之前的 ES 使用 基于属性的分片分配过滤 实现冷热架构中的 data tiers 间 index 迁移；如今 ES 内置的节点角色以及自动 data tier allocation 可以让 ILM 自动在 data tiers 间迁移 indices
对于自管理部署，需要手动更新配置、ILM 策略，以及 index ，来更换到节点角色。使用节点角色，需要：
将数据节点注册为合适的 data tier
从 index 生命周期管理策略中删除基于属性的分片分配过滤
停止在新的 index 上设置自定义的 hot 属性
在新的 index 上执行默认的 tier 优先级
更新现有的 index 设置 tier 优先级
3.1 将数据节点分配到 data tier
通过给每个数据节点配置合适的角色，可以将其分配到一个或多个 data tiers 中，节点角色可以设置为：
data_hotdata_contentdata_warmdata_colddata_frozen
参考：节点角色
默认情况下，新节点配置为所有角色
方法1：使用 更新部署API
在项 ES 服务部署中添加一个 data tier 时，一个或多个节点会自动配置相关的角色。为了显式地修改 ES 服务部署中地节点地角色，可以使用 Update deployment API。替换节点的 node_type 配置为合适的 node_roles 。例如，以下的配置将节点添加到 hot 和 content tiers，并且使它扮演 ingest 节点、remote 和 transform 节点
"node_roles": [
"data_hot",
"data_content",
"ingest",
"remote_cluster_client",
"transform"
],
方法2：手动配置 elasticsearch.yml
可以直接通过配置集群中的节点的配置文件达到同样效果，例如添加以下设置将使节点成为 hot 和 content tiers 中的 data-only 节点。
node.roles [ data_hot, data_content ]
3.2 从现有 ILM 策略中删除指定的分配设置
更新每个生命周期阶段中的 allocate 动作，移除 attribute-based 分配设置。这会使 ILM 向每个阶段注入 migrate 动作，从而自动的将 index 在 data tiers 间转移。
如果 allocate 动作不设置副本数量，将 allocate 动作整个移除（一个空的 allocate 动作无效）
重要：在你的架构中，必须给每个 data tier 指定相关的阶段。每个阶段都必须存在，从而 ILM 可以注入 migrate 动作。如果不需要执行其他动作，阶段可以为空。例如，如果你开启了部署中的 warm 和 cold data tiers，策略必须包含 hot，warm 和 cold 阶段。
3.3 停止在新的 index 上设置自定义的 hot 属性
当直接创建 index 时，index 自动分配到 data_content 节点。（当创建一个 data stream，其第一个 backing index 会自动分配到 data_hot 节点）
在 ES 服务部署中，删除 cloud-hot-warm-allocation-0 index 模板，该模板会设置所有的 index 上的 hot shard allocation 属性
DELETE _template/.cloud-hot-warm-allocation-0
如果使用的是自定义 index 模板，需要移除其中你用于分配新的 index 到 hot tier 的 attribute-based allocation filters
为完全避免在混合 tier 优先级、自定义属性路由设置时会产生的问题，建议更新所有遗留模板、可组合模板和组件模板，以 从它们配置的设置中删除基于属性的分配过滤器。
3.4 在新的 index 上执行默认的 tier 优先级
设置 [cluster.routing.allocation.enforce_default_tier_preference](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/modules-cluster.html#enforcing-a-default-tier-preference) 为 true，之后创建的 index 会有 _tier_preference 属性，覆盖 create index API 或相关的 index template，如果这些设置中存在 null（newly created indices will have a _tier_preference, overriding the create index API or an associated index template, if either of those specifies null for the setting.）
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enforce_default_tier_preference": true
}
}
3.5 给已存在的 index 配置 tier 优先级
ILM 通过自动向每个阶段自动注入一个 migrate 动作实现自动转变管理中的 index 到可用的 data tiers
为了让 ILM 能在 data tiers 中移动已存在的受管理 index，更新 index 的配置：
通过设置自定义 allocation 过滤器为 null 将其移除
举例：旧的模板 data 属性为 hot，将分片都分配到 hot tier，设置 data 为 null ，设置 _tier_preference 为 data_hot
PUT my-index/_settings
{
"index.routing.allocation.require.data": null,
"index.routing.allocation.include._tier_preference": "data_hot"
}
对于已经转移出 hot 阶段的 index，其 tier 优先级应该包含合适的回滚 tiers 来保证 index 分片可以在首要的 tier 不可用时得到分配。例如指定 hot tier 作为 index 已经处于 warm 阶段的回滚
PUT my-index/_settings
{
"index.routing.allocation.require.data": null,
"index.routing.allocation.include._tier_preference": "data_warm,data_hot"
}
同样，如果 index 已经处于 cold 阶段，需要包含 cold, warm, hot tiers
对于同时配置了 _tier_preference 和require.data 的 index，如果_tier_preference 过期了（例如，节点配置属性比 _tier_preference 配置还要“冷”），迁移需要删除 require.data 属性并更新 _tier_preference 从而映射到正确的 tier。例如，对于以下路由配置的index：
{
"index.routing.allocation.require.data": "warm",
"index.routing.allocation.include._tier_preference": "data_hot"
}
路由配置需要改成：
PUT my-index/_settings
{
"index.routing.allocation.require.data": null,
"index.routing.allocation.include._tier_preference": "data_warm,data_hot"
}
4. 管理已有 index
对于先前没有使用管理工具托管的 index，有两种方法迁移到 ILM
设置 index 模板来应用 ILM 策略，从而管理新的 index。一旦 ILM 开始管理现有的写 index，就可以将合适的策略应用到旧的 index 上。
重新索引到 ILM 托管的 index
4.1 给已有的时间序列 index 应用策略
最简单的方法让 ILM 管理周期性的 index 就是修改 index 模板，将生命周期策略应用到新 index 上。一旦 ILM 开始管理写 index，你就可以手动的给旧 index 应用策略
额外定义一条策略给旧的 index，并去掉 rollover 动作。 Rollover 用于管理新数据的位置，因此不需要。
记住给已存在 index 应用的策略用每个阶段的 min_age 比较 index 的创建日期，并且可能会立刻处理多个阶段。如果你的策略执行类似 force merge 这种源敏感操作，当你切换到 ILM时，你不会希望许多 index 一次性执行这些操作。
可以通过设置不同的 min_age 值给不同 index 的不同策略，或设置 [index.lifecycle.origination_date](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/ilm-settings.html#index-lifecycle-origination-date) 控制 index age 的计算方法
一旦所有的 pre-ILM index 年龄到期并且移除了，就可以删除用于管理他们的策略
4.2 重新索引到被托管 index
另外一种给已有 index 应用策略的方法时 reindex 数据到一个 ILM 托管的 index。
当使用少量数据周期性创建 index 导致过多的分片计数时，或持续向同一个索引中 indexing 数据导致产生超大分片和性能问题时，这是个好的选项。
首先，需要设置新的 ILM 托管 index：
更新 index 模板，嵌入必须的 ILM 设置
启动一个初始化 index 作为写 index
停止向旧 index 写入，将新文档使用别名导入到刚启动的写 index 中
重新索引到托管 index：
暂停 indexing 新文档，这样可以避免新老数据混淆在 ILM 托管的 index 中
-
减小 ILM 轮询间隔，确保在等待 rollover 检查时 index 不会涨到太大。默认 ILM 每10分钟检查动作条件
PUT _cluster/settings { "persistent": { "indices.lifecycle.poll_interval": "1m" } } -
使用 reindex API 重新索引数据。如果需要将数据按照原来索引的顺序分开引导，可以运行 separate reindex requests
如果需要 reindex 时保留原文档的 id，并且是从多个原 index 进行 reindex，需要额外的过程来保证 文档 id 不冲突。一种方法是在 reindex call 中使用 script 来扩展源 index 名到文档 id
POST _reindex { "source": { "index": "mylogs-*" }, "dest": { "index": "mylogs", "op_type": "create" //当多个文档有相同 id 时，暂停。推荐，可以防止在从多个index中来的文档因ID重复而被覆盖 } } -
当 reindex 完成，设置 ILM 轮询间隔倒退回默认值，防止主节点非必要的负载
PUT _cluster/settings { "persistent": { "indices.lifecycle.poll_interval": null } } 恢复使用相同的别名引导新数据。使用这个别名来进行检索，将会检索新数据以及所有的 reindexed 数据
验证所有 renindexed 数据在新的托管 index 上可访问后，可以安全的移除旧index
