ES 7.12官网阅读-ILM（index lifecycle management）

官网文档：ILM: Manage the index lifecycle | Elasticsearch Guide [7.12] | Elastic

ILM：管理 index 的生命周期

可以根据你的性能、弹性、保存时长需求，使用ILM策略来自动管理你的index；比如

1. 当一个index达到确定的大小，或者一定数量的documents的时候，启动一个新索引；

2. 按照每天、每周、每月创建新index，并归档之前的index；

3. 删除过期index来执行数据保留标准；

可以通过kibana 管理界面或者ILM 的API来创建和配置ILM策略，当你给Beats或Logstash Elasticsearch的输出插件启用了ILM，默认的策略会自动配置；

自动备份你的index和管理你的snapshots，使用snapshot lifecycle policies；

ILM 可以触发哪些动作

Rollover：当当前index达到确定的大小，确定数量的docs（document）或者期限，创建一个新的index；

Shrink：减少索引中主分片的数量；

Force merge：手动触发发一个merge 来减少index shards 中的segments数量

Freeze： 使index 制度并且最小化内存占用；

Delete：永久删除一个index，包括元数据（metadata）和数据（data）

ILM 使管理在hot-warm-cold架构中的索引变得简单，当你处理日志和指标（metrics)等时间序列数据是，这很常见；

你可以指定：

        1. 你想要滚动到新索引的最大分片大小、文档数量或期限

        2. 不再更小索引并可以减少主分片数量的点；

        3. 何时强制合并并永久删除标记为删除的文档；

        4. 可以将索引移至性能较低的硬件的点；

        5. 可用性不那么重要并且可以减少副本数量的点；

        6. 何时index 可以被安全删除；

举个例子，如果您要将 ATM 机群中的指标数据索引到 Elasticsearch 中，您可以定义一个策略：

        1. 当index 的主分片大小达到50GB，roll over（滚动）到一个新索引；

        2. 将旧的index移动到warm 阶段（phase），标记制度，并且将其缩小为单个shard；

        3. 7天后，移动到cold阶段（phase），并且移动到更便宜（less expensive）的硬件上；

        4. 达到要求的30天保留期后删除索引；

使用ILM的注意事项：使用ILM，一个集群中的所有节点都必须运行相同的版本（version),隋岩可能会在混合的版本中创建和应用策略，但是不保证按照预期执行。尝试使用非所有节点都支持的的策略，可能会导致错误

ILM 概念

index 生存周期（lifecycle)

ILM 定义了五个index生存周期阶段（phases）：

Hot：该索引正在积极的更新和查询；

Warm：该索引不再被更新但是仍然被查询；

Cold：该索引不再更新，查询也不再频繁，信息仍然需要可搜索，但如果这些查询速度较慢也没关系；

Frozen：该索引不再被更新，很少查询，信息仍然需要被搜索，但如果这些查询速度特别慢也没关系；

Delete：该索引不再被需要，并可以被安全删除；

一个index 生存周期管理策略指定了哪些阶段适用，在每个阶段什么动作被执行，以及何时在阶段之间转换。

你可以在你创建一个index 的时候，手动应用一个lLM策略，对于时间序列索引，你需要关联ILM策略到用于创建新的时序index的index template。当一个index 滚动（roll over）创建，一个手动应用的策略不会自动应用到新的index。

如果你使用Elasticsearch安全特性，ILM以上次更新策略的用户身份执行操作，ILM 仅具有上次策略更新时分配给用户的角色权限；

阶段转换（Phase transitions）

ILM通过他们的存在期限来移动index，为了控制他们的转换时间，你可以为每个阶段设置一个最小期限（minimum age），对于一个移动到下一阶段的index，所有在当前阶段的action（动作）必须完成，并且索引必须早于下一阶段的最小期限（minimum age）；

默认最小期限（minimum age）默认是0 ，这会导致ILM在当前阶段的所有操作完成后立即将索引移动到下一阶段；

如果一个index 存在未分配（unallocated）分片（shard）或者集群状态（cluster health status）是yellow，index仍能够根据ILM策略转换到下一个节点。然而因为Elasticsearch只能在Green的状态下才能执行确认的清理任务，这可能造成想不到的副作用（side effects）

避免增加磁盘使用率和可靠性问题，及时（in timely fashion)定位所有集群健康问题

阶段执行（Phase execution）

ILM控制阶段中操作的执行顺序以及执行哪些步骤来执行每个所需的索引操作。

当一个index 进入一个阶段（phase）ILM 在index 的元数据（metadata）中缓存这个阶段（phase）定义。这样确保策略更新不会使索引陷入到永远无法退出阶段的状态，如果修改（changes）能够被安全的应用，ILM更新缓存的阶段定义，如果他们不能，阶段执行继续使用缓存的定义。

ILM周期性运行，检查是否有index 满足策略标准（criteria），并执行所需的任何步骤。避免竞争（race）条件，ILM可能需要运行多次才能执行完成操作所需的所有步骤。例如，如果ILM确定一个索引已经满足了rollover（滚动更新）标准（criteria),ILM开始执行完成rollover（滚动更新）所需的所有步骤，如果达到无法安全进入下一步的程度，则执行停止，下一次ILM运行时，ILM将从中断处继续运行。这意味着即使indices.lifecycle.poll_interval 是设置的是10分钟，并且一个index满足rollover（滚动更新）criteria（标准），可能会花费20分钟来完成rollover

阶段动作（Phase actions）

在每个阶段ILM支持的动作（action）如下；

Hot

        Set Priority

        Unfollow

        Rollover

        Read-Only

        Shrink

        Force Merge

Warm

        Set Priority

        Unfollow

        Read-Only

        Allocate

        Migrate

        Shrink

        Force Merge

Cold

        Set Priority

        Unfollow    

        Allocate

        Freeze

        Searchable Snapshot

Frozen

        Searchable Snapshot

Delete

        Wait for Snapshot

        Delete

Rollover(滚动更新）

当你索引（indexing）像日志（log）或者指标（metrics）你不可能无限期（indefinitely）写入到一个单独的index中。为了满足你的indexing和查询性能要求以及管理资源使用率，当你写入的index达到一个阈值的时候，创建一个新的index，并开始往新的index 中写入。使用滚动创建indices是你能够做：

• 优化活动索引，以实现高效能hot节点上的高摄取率（ingest rates）；
• 优化warm节点上的搜索性能；
• 将旧的，访问频率较低的数据转移（shift)到成本较低的cold节点；
• 通过删除整个索引，根据你的保留策略删除数据；

我们推荐你使用data streams 来管理时序数据。Data streams自动跟踪写入索引，同时将配置保持在最低限度；

每个data streams要求一个index template包括：

• 数据流的名称或通配符（*）模式（wildcard pattern）
• 数据流时间戳字段，这个字段必须映射为date或者date_nanos字段数据类型，并且必须包含在index到data stream的每个文档中；
• 创建每个支持（backing）index的映射（mapping）和设置（setting）

Data streams专为附加数据（append-only）而设计，其中data stream 名称可用作（读、写、滚动更新（rollover）、收缩（shrink） 等）目标；如果你的用例需要就地更新数据，你可以使用索引别名（index aliases）来管理时序数据；然而，这里有一些额外的配置步骤和概念：

• 索引模版，指定时序中每个新索引的配置，你可以优化此配置以进行摄取（ingest），通常使用与hot节点数量一样多的分片。
• 引用整个索引集的索引别名；
• 指定为写索引的单个索引，这是处理所有写入请求的活动index，每次rollover是，新索引将会成为写入索引；

自动滚动更新（Automatic rollover）

ILM使你能够基于index 大小，document数量，保存时间（age）自动滚动更新（automatic rollover），当一个rollover 被触发，一个新的index 被创建，一个写别名（write alias）被更新执行新索引，索引后续的更新被写入到新的index；

TIP：根据大小、文档计数或期限（age）滚动到新索引比基于时间的滚动更可取。在任意时间（arbitrary time）rollover通常会产生许多小索引，这可能会对性能和资源使用产生负面影响。

Policy updates（策略更新）

你可以通过修改当前策略或切换到不同的策略来更改索引或滚动索引集合的生命周期的管理方式。

为了确保策略更新不会将索引置于无法退出当前阶段的状态，阶段定义在进入该阶段时会缓存在索引元数据中。如果可以安全地应用更改，ILM 会更新缓存的阶段定义。如果不能，阶段执行将继续使用缓存的定义。

当索引前进到下一阶段时，它使用更新策略中的阶段定义

如何应用修改（How changes are applied ）

当策略最初应用于索引时，索引获取最新版本的策略，如果更新策略，策略版本会发生变化（bumped），并且 ILM 可以检测到索引正在使用需要更新的早期版本。

对 min_age 的更改不会传播到缓存的定义。更改阶段的 min_age 不会影响当前正在执行该阶段的索引

例如，如果您创建的策略具有未指定 min_age 的热阶段，则应用该策略时索引会立即进入热阶段。如果您随后更新策略以将热阶段的 min_age 指定为 1 天，则这对已处于热阶段的索引没有影响。策略更新后创建的index要到一天后才会进入热门阶段 。                                   

如何应用新策略（How new policies are applied）

当您将不同的策略应用于托管索引时，索引将使用先前策略中的缓存定义来完成当前阶段。该指数在进入下一阶段时开始使用新政策。