Elastic：索引生命周期管理(Index Lifecycle Management)-减轻ES存储压力-CSDN博客

本文链接：https://blog.csdn.net/liupenglove/article/details/148373985

1、es数据生命周期管理面临的问题

在使用Elasticsearch过程中，随着业务的持续增长，历史数据长期堆积引发的磁盘空间不足、查询延迟飙升等问题变得越来越突出，严重影响了业务的正常运行，如何实现数据的冷热处理以及数据自动清理，成为了团队面临的核心问题。

在es中，数据的清理有两种技术方案：

在文档的维度上，使用_delete_by_query+forcemerge的方案，删除符合检索条件的数据，前面文章有介绍：Elasticsearch：delete_by_query使用方法
在索引的维度上，使用Index Lifecycle Management(ILM)机制，实现对整个索引的自动化管理。

这两种方案各自有其特有的使用场景：

第一个方案，适用于数据量较小，临时进行数据清理的场景，灵活性比较高，控制粒度较细，可以对特定的文档进行操作。

但他有一个致命的缺点：资源消耗惨烈，cpu、io要承受巨大的压力。

而对于第二种方案，可以定义索引的生命周期策略，在不同阶段可以定义特定的策略：

Rollover：当索引达到阈值（如50GB/7天）时创建新索引

ForceMerge+Shrink：在Warm阶段合并段并减少分片数

Freeze：在Cold阶段冻结索引，释放堆内存

Delete：在Delete阶段自动删除过期索引

这种方案适用于数据量较大，需要定期清理的场景，而且对资源的占用较少，不需要进行forcemerge操作，出现问题的风险很低，推荐使用这种方式，我们重点介绍这种方式。

2、什么是ILM

Index Lifecycle Management (ILM) 是elastic的一个核心功能，旨在自动化管理索引随时间变化的生命周期过程，它的核心思想是：数据在其生命周期的不同阶段具有不同的访问模式和存储需求。 ILM 允许你定义策略，根据索引的年龄、大小或其他条件，自动将其从一个生命周期阶段转换到下一个阶段，并在每个阶段应用相应的优化操作。

为什么需要ILM？

简化管理： 手动管理大量索引（尤其是滚动创建的索引，如按天创建的日志索引）非常繁琐且容易出错。ILM 自动化了这个过程。
优化性能和成本：
- 热阶段： 最新、最活跃的数据存储在性能最优（通常也是最昂贵）的硬件（SSD）上，确保快速读写。
- 温阶段： 数据访问频率降低，可以转移到性价比更高的硬件（如 SAS/SATA SSD 或高速 HDD），并进行压缩等优化。
- 冷阶段： 很少访问的数据可以转移到成本极低的存储（如大容量 HDD 或对象存储），通常只读。
- 删除阶段： 过期或不再需要的数据自动安全删除，释放资源并可能满足合规要求。
提升资源利用率： 避免昂贵资源被很少访问的“冷”数据长期占用。
自动化数据留存： 轻松定义数据保留策略，确保数据在需要时可用，在过期时清理。

ILM 的核心概念

生命周期阶段 (Lifecycle Phases): 定义了索引在其生命周期中经历的不同状态。Elasticsearch 预设了四个主要阶段：
- hot： 索引正在被积极地写入和频繁查询。主要操作：rollover (创建新索引写入)， shrink (可选，减少主分片数)， force merge (可选，合并段减少开销)。
- warm： 索引不再写入，但仍会被定期查询。平衡性能和成本。主要操作：allocate (将分片移动到温节点)， force merge (优化只读索引)， shrink (可选)。
- cold： 索引很少被查询，但可能偶尔需要访问。优先考虑低成本存储。主要操作：allocate (将分片移动到冷节点)， searchable snapshot (可选，在冷阶段或之前创建，将数据高效存储在对象存储上)。
- delete： 索引已过期，不再需要。主要操作：delete (永久删除索引及其数据)。
- (注意：frozen 阶段在较新版本中被整合进 cold 阶段，主要通过 searchable snapshot 实现高效冻结/解冻)。
动作 (Actions): 在每个阶段内可以执行的具体操作（如 rollover, allocate, force merge, freeze, unfollow, shrink, set_priority, delete, wait_for_snapshot, searchable_snapshot 等）。动作按顺序执行。
转换 (Transitions)： 定义索引何时以及基于什么条件从一个阶段进入下一个阶段。最常见的条件是索引的年龄（如创建后 3 天进入 warm，7 天后进入 cold，30 天后 delete）。也可以基于文档数或索引大小（主要与 rollover 结合用于 hot 阶段）。
索引别名 (Index Alias)： 在 hot 阶段使用 rollover 动作时至关重要。写入操作指向一个别名（如 logs-current），而不是具体的索引名。当满足 rollover 条件（如索引达到 50GB 或创建超过 7 天）时，ILM 会自动创建一个新索引，并将写入别名切换到新索引，旧索引进入下一个生命周期阶段。
ILM 策略 (ILM Policy)： 这是你定义的蓝图或规则集。它明确指定了：
- 包含哪些阶段。
- 每个阶段内的动作及其配置（如 max_primary_shard_size 用于 rollover）。
- 阶段之间的转换条件（如 min_age）。
- 一个索引只能关联一个 ILM 策略。

3、ILM使用示例

就以我现在项目中的真实需求为例来说明ILM的使用原理，这样更贴近实战一些。

我当前的项目中，由于前期没有设计数据的删除机制，随着业务增长，es的存储量在一个季度的时间翻了一倍，硬盘存储占用超过60%，且在查询、写入高峰，cpu占用80%以上，照当前数据的增速，再有2个月，es完全就会被打爆了。

目前我们索引是按月生成的，两个好处，第一，单索引不会过大，第二，根据检索条件中的时间设置，可以直接找到要检索的索引，因此当前我的需求是：设计一个机制，实现索引的按月自动化创建，超过一年的数据(索引)，自动化删除。

对于每月索引的这种场景，在ILM里设置不太实用，需要另行设计自动化的机制实现为每个月创建索引。

1、创建ILM策略


PUT _ilm/policy/scene_tag_monthly_rollover_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {}
      },
      "delete": {
        "min_age": "12M",           
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

在kibana执行以上指令：

也可以通过在kibana输入命令行查看：

GET _ilm/policy/scene_tag_monthly_rollover_policy

2、创建索引模板

PUT _index_template/scene_tag_monthly_naming_template
{
  "index_patterns": ["new_tag.*"], 
  "template": {
    "settings": {
      "number_of_shards": 1,
      "number_of_replicas": 1,
      "index.lifecycle.name": "scene_tag_monthly_rollover_policy",
    }
  },
  "priority": 100
}

运行结果如下：

3、每月创建索引

这个操作可以由程序自动化触发，索引名称必须设置为new_tag.*格式，比如new_tag.202505，这种格式的索引就会自动应用上面创建的ILM策略。

创建索引：


PUT /new_tag.202505
{
}

查看索引是否绑定了ILM：


GET /new_tag.202505/_settings

返回信息：

{
  "new_tag.202505": {
    "settings": {
      "index": {
        "lifecycle": {
          "name": "scene_tag_monthly_rollover_policy"
        },
        "routing": {
          "allocation": {
            "include": {
              "_tier_preference": "data_content"
            }
          }
        },
        "number_of_shards": "1",
        "provided_name": "new_tag.202505",
        "creation_date": "1748697616420",
        "number_of_replicas": "1",
        "uuid": "Tz4aBFKuQWCYMaz4VhYVTA",
        "version": {
          "created": "8521000"
        }
      }
    }
  }
}

这个new_tag.202505索引会在2026.05被删除。