Linux下部署Elasticsearch ILM需构建策略、模板、别名、索引闭环链路:先确认≥7.0版本、安全启用、JVM与磁盘合理;再创建三阶段策略并验证;通过模板绑定策略、别名支撑rollover;最后持续监控执行状态与故障原因。
在 Linux 下部署 Elasticsearch 索引生命周期管理(ILM),核心不是装完 ES 就能用,而是把策略、模板、别名和实际索引串成一条自动运转的链路。重点在于配置闭环——策略定义行为,模板绑定策略,别名支撑滚动,索引按规则演进。
ILM 是 7.0+ 内置功能,8.x 默认启用且更稳定。先验证:
curl -X GET "localhost:9200/" 查看版本号,确保 ≥ 7.0xpack.security.enabled: true 是否开启(生产环境必须开,否则 ILM 策略可能被拒绝)-Xms4g -Xmx4g 起步,避免因 GC 导致 ILM 协调器卡顿)path.data 指向的路径有足够余量(ILM 删除前会先做段合并,临时占用翻倍)策略是 ILM 的“大脑”,需明确定义各阶段触发条件和动作。例如日志类场景常用三阶段:
"max_docs": 10000000 或 "max_size": "50gb",满足任一即滚动"min_age": "7d",之后执行 "forcemerge": {"max_num_segments": 1} 和 "readonly": {}
"min_age": "90d",触发 "delete": {}
创建后立即验证:GET _ilm/policy/my-policy 看是否生效;再用 GET _ilm/explain/my-index 检查某索引当前所处阶段和剩余等待时间。
模板让新索引“天生自带”ILM,别名则是 rollover 的必要前提:
"index.lifecycle.name": "my-policy"
"index.lifecycle.rollover_alias": "logs-write"(该别名需提前存在,且指向首个索引)PUT logs-000001POST logs-000001/_alias/logs-write
POST logs-write/_doc,ILM 自动在满足条件时新建 logs-000002 并切换别名ILM 不是设完就高枕无忧,需持续关注几个关键点:
GET _cat/ilm/policies?v 查看策略状态,GET _cat/ilm/explain?v 批量检查各索引执行进度_cluster/allocation/explain,尤其 rollover 失败常因分片无法分配(比如 warm 阶段要求迁移到特定节点但磁盘已满)GET _cat/tasks?v&actions=*delete* 查看阻塞任务