一、为什么要给索引设生命周期管理？
1.1 没有ILM的痛点
我之前接触过一个做电商的朋友，他们的nginx日志系统上线3年，从来没管过旧数据，结果ES集群的磁盘从最初的100GB涨到了15TB，运维每周要手动删几个G的旧索引，好几次删错了正在备份的日志，被监管部门警告，而且查去年的订单日志时，ES要扫所有15TB的索引，页面加载要半分钟，用户投诉特别多。其实这不是个例，很多用Elasticsearch存日志、监控数据的团队，都会遇到这个问题：数据越堆越多，磁盘爆了，查询越来越慢，人工清理又麻烦还容易出错。
1.2 ILM能解决什么问题
ILM就是Elasticsearch给索引定的「生命周期时间表」，简单说就是给索引分阶段，每个阶段做不同的事：新生成的索引叫「热阶段」，放常用的新数据，速度要快；7天后不常用了就转「暖阶段」，合并分片省资源；再过几十天不用了转「冷阶段」，放在低速磁盘；最后到时间自动「删除」，不用人管。这样就能自动清理旧数据，不会占满磁盘，查数据的时候只需要扫近期的，速度也快。
二、ILM的核心逻辑是什么？
2.1 四个阶段的分工
ILM的四个阶段就像快递的处理流程：
- 热阶段（hot）：刚到的快递，放在前台（热节点，高速磁盘），随时能取；
- 暖阶段（warm）：放了7天没人取的快递，搬到仓库（暖节点，低速磁盘），不用随时取，但还要留着；
- 冷阶段（cold）：放了30天没人取的快递，放在地下室（冷节点，超低速磁盘），基本不用找；
- 删除阶段（delete）：放了1年没人取的快递，直接扔掉，占地方。 每个阶段都能设置触发条件，比如热阶段7天后自动转暖，暖阶段30天后自动删，或者索引满50GB就自动滚动（生成新索引，旧的转下一阶段）。
2.2 自动流转的流程
ILM的自动流转不需要人工干预，每次ES的后台任务会检查每个索引的状态，符合某个阶段的条件就自动触发动作。比如索引「nginx-logs-000001」在热阶段待了7天，后台就会把它转去暖阶段，然后生成新的索引「nginx-logs-000002」，应用只要用同一个别名（比如nginx-logs-alias），就能自动读新索引，不用改应用代码。
三、实战配置完整步骤
我用一个具体的例子来一步步说，我们要做的是nginx日志的ILM策略：热阶段7天，满50GB就滚动；暖阶段转1个分片，30天后删除。
3.1 第一步：创建ILM策略
首先要在ES里创建这个策略，用API配置，直接发JSON过去，示例如下：
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": { // 滚动动作，触发新索引生成
"max_age": "7d", // 热阶段最长7天，到了自动滚动
"max_size": "50gb" // 索引最大50GB，触发滚动的第二个条件，满足一个就生效
}
}
},
"warm": {
"min_age": "7d", // 从热阶段转暖阶段的最小等待时间，必须满7天才能转
"actions": {
"shrink": { // 合并分片，减少资源占用，原3个分片合并为1个
"number_of_shards": 1
},
"allocate": { // 把索引分配到暖节点，让热节点留给新数据
"require": {
"data": "warm" // 暖节点的标识，ES节点配置时需添加对应标签
}
}
}
},
"delete": {
"min_age": "30d", // 从索引生成到删除的最小时间，必须满30天才能删
"actions": {
"delete": {} // 执行删除动作，也可改成归档到对象存储更安全
}
}
}
}
}
然后用curl命令把这个策略提交到ES，假设ES在本地9200端口，把上面的内容存成ilm_policy.json，然后执行：
# 向ES发送请求，创建名为logs_ilm_policy的ILM策略
curl -X PUT "http://localhost:9200/_ilm/policy/logs_ilm_policy" -H "Content-Type: application/json" -d @ilm_policy.json
3.2 第二步：关联到索引模板
现在策略有了，要让新生成的索引自动用这个策略，需要配置索引模板，模板会匹配所有叫「nginx-logs-*」的索引，示例如下：
{
"index_patterns": ["nginx-logs-*"], // 匹配所有nginx-logs开头的索引
"settings": {
"number_of_shards": 3, // 初始3个分片，热阶段会合并为1个
"number_of_replicas": 1, // 1个副本，保证数据不丢失
"index.lifecycle.name": "logs_ilm_policy", // 关联刚才创建的ILM策略
"index.lifecycle.rollover_alias": "nginx-logs-alias" // 滚动用的别名，应用只需读这个别名
}
}
同样用curl提交模板，存成index_template.json，执行：
# 创建名为nginx_logs_template的索引模板
curl -X PUT "http://localhost:9200/_index_template/nginx_logs_template" -H "Content-Type: application/json" -d @index_template.json
3.3 第三步：测试新索引
现在可以手动生成一个测试索引，用别名来写，这样会自动匹配模板规则：
# 向别名写入测试日志，ES会自动生成符合规则的索引
curl -X POST "http://localhost:9200/nginx-logs-alias/_doc" -H "Content-Type: application/json" -d '{"message":"test nginx log","timestamp":"2024-05-20"}'
正常情况下，会自动生成类似「nginx-logs-000001」的索引，再过7天会自动生成「nginx-logs-000002」，旧的索引转暖阶段，30天后自动删除。
四、怎么监控ILM的运行？
4.1 用命令行查状态
ES提供了简单的API，不用复杂工具就能看ILM的运行情况：
# 查看刚才创建的ILM策略，确认提交成功
curl -X GET "http://localhost:9200/_ilm/policy/logs_ilm_policy"
# 查看某个索引的ILM状态，比如刚生成的nginx-logs-000001
curl -X GET "http://localhost:9200/nginx-logs-000001/_ilm/explain"
如果输出里的「phase」是「hot」，「action」是「complete」，就说明正常；如果是「error」，就需要排查原因，比如磁盘满了、节点标签配置错了、策略时间设置不合理。
4.2 常见问题排查
比如遇到索引不能滚动，先看磁盘剩余空间，ES默认需要至少10%的可用空间才能触发滚动，不够的话要么扩容磁盘，要么调整max_size参数；还有如果设置了warm节点，要确保ES集群里有带「data: warm」标识的节点，不然暖阶段会卡住，解决方式要么加暖节点，要么删除warm阶段直接从热转cold或delete。
五、场景、优缺点和注意事项
5.1 适合用ILM的场景
ILM最适合时序数据，也就是按时间顺序生成、越旧价值越低的数据，比如：
- 服务器、应用的日志（nginx、tomcat、业务系统日志）；
- 监控数据（CPU、内存、磁盘的时序指标）；
- 电商的交易、操作日志（只需保留近期的，旧的按合规要求处理）；
- 用户行为日志（点击、浏览、停留数据，一般保留30天用于分析）。 如果是静态数据，比如商品信息、用户档案，不用ILM，因为旧数据还是有价值的。
5.2 ILM的优缺点
优点：
- 全自动化，不用人工删索引，减少运维重复劳动，避免删错重要数据；
- 合理利用磁盘，不会让集群被旧数据占满，避免因为磁盘满导致ES宕机；
- 优化查询性能，旧数据自动分层存储，查近期数据不需要扫全量索引，速度提升明显；
- 支持分层存储，热数据放高速磁盘，冷数据放低速磁盘或对象存储，节省硬件成本。 缺点：
- 规则设置错误容易丢数据，比如删除时间设太短，把合规要求要保留的日志删掉；
- 对非时序数据没用，无法发挥自动化管理的优势；
- 调整规则需要谨慎，必须在测试环境验证后再上生产，不然影响数据可用性。
5.3 必须注意的坑
- 重要数据一定要做备份，哪怕设了delete阶段，也要定期做快照，防止误删或集群故障丢数据；
- 规则参数要根据实际数据量调整，比如日志多的话，max_size设成20GB，max_age设成3天，避免单个索引太大；
- 合规要求的场景，比如医疗、金融的日志要保留6个月，delete的min_age一定要设够，不能随便改短；
- 必须先在测试环境跑一遍完整流程，看索引转换、删除是否正常，有没有报错，确认没问题再上线；
- 要给ILM设置监控告警，比如滚动失败、删除失败时及时通知运维，避免问题积累。
六、总结
ILM是Elasticsearch针对时序数据的实用功能，配置逻辑清晰，只要理清四个阶段的分工，写对策略和索引模板，就能实现索引的自动滚动和删除，彻底解决旧数据占磁盘、查询慢的痛点。不管是新手还是有经验的开发者，都能通过实战配置快速上手，把运维从手动删索引的重复劳动里解放出来，把精力放在更核心的业务逻辑优化上。
Comments