Elasticsearch索引生命周期管理ILM的核心概念

Elasticsearch索引生命周期管理（Index Lifecycle Management, ILM）是ES内置的自动化索引管理策略，根据索引年龄或大小自动执行rollover、shrink、forceMerge、freeze、delete等操作。日志、监控指标、业务事件等时序数据天然具有冷热特征：近期数据高频访问，历史数据偶尔查询，超过保留期的数据直接删除。ILM将这些运维决策声明式配置，免去了手动管理成百上千个索引的工作量。

ILM定义四个阶段，按顺序执行：Hot（热阶段，索引正在写入）、Warm（温阶段，索引不再写入但仍需查询）、Cold（冷阶段，索引极少查询可冻结）、Delete（删除阶段，索引超期删除）。每个阶段可配置一个或多个动作，动作之间串行执行。

ILM策略配置与Rollover机制

Rollover是ILM最核心的动作，当一个索引达到指定条件（大小、年龄、文档数）时，自动创建新索引并将写入别名指向新索引。旧索引进入温/冷阶段处理。

ILM策略定义示例：

PUT _ilm/policy/logs-policy
{
"policy": {
"phases": {
"hot": {
"min_age": "0ms",
"actions": {
"rollover": {
"max_primary_shard_size": "50gb",
"max_age": "7d",
"max_docs": 100000000
},
"set_priority": {
"priority": 100
}
}
},
"warm": {
"min_age": "7d",
"actions": {
"shrink": {
"number_of_shards": 1
},
"forcemerge": {
"max_num_segments": 1
},
"allocate": {
"number_of_replicas": 1,
"require": {
"data": "warm"
}
},
"set_priority": {
"priority": 50
}
}
},
"cold": {
"min_age": "30d",
"actions": {
"freeze": {},
"allocate": {
"require": {
"data": "cold"
}
},
"set_priority": {
"priority": 0
}
}
},
"delete": {
"min_age": "90d",
"actions": {
"delete": {}
}
}
}
}
}

该策略的工作流程：索引写入期间（Hot），任一shard达到50GB或索引满7天或文档数达1亿，触发rollover创建新索引。rollover后的旧索引7天后进入Warm阶段，shrink到1个shard并forceMerge到1个segment，迁移到warm节点。30天后进入Cold阶段冻结，迁移到cold节点。90天后自动删除。

冷热数据分层节点架构设计

ILM的allocate动作依赖节点的属性标签。冷热分层架构通过为不同规格的节点打data属性标签，ILM根据阶段自动将索引迁移到对应节点。

节点elasticsearch.yml配置：

# Hot节点：NVMe SSD，高配CPU/内存
node.roles: [data_hot]
node.attr.data: hot

# Cold节点：大容量HDD，低配
node.roles: [data_cold]
node.attr.data: cold

ES 7.x以后支持node.roles直接定义data_hot/data_warm/data_cold角色，无需手动打属性标签。ILM的allocate动作会自动识别节点角色进行迁移。Hot节点通常配备NVMe SSD和充足内存（128GB+），以支撑高频写入和查询。Warm节点使用SATA SSD降低成本，Cold节点使用HDD阵列或对象存储（通过Frozen Tier）。

ILM策略应用与索引模板绑定

ILM策略通过索引模板绑定到索引。创建索引模板时指定settings.ilm.name，新创建的索引自动继承策略：

PUT _index_template/logs-template
{
"index_patterns": ["logs-*"],
"template": {
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1,
"index.lifecycle.name": "logs-policy",
"index.lifecycle.rollover_alias": "logs"
}
}
}

创建第一个索引并绑定写入别名：

PUT logs-000001
{
"aliases": {
"logs": {
"is_write_index": true
}
}
}

此后应用写入logs别名，ILM在条件满足时自动rollover创建logs-000002、logs-000003等索引，写入别名始终指向最新索引。

ILM运维常见问题与调优

ILM策略变更不会立即生效于已有索引。修改策略后，新rollover的索引使用新策略，已有索引保持旧策略。需要手动更新已有索引的ILM策略：

PUT logs-000001/_settings
{
"index.lifecycle.name": "logs-policy-v2"
}

Rollover条件中的max_primary_shard_size是推荐的最佳实践。传统按索引总大小rollover会导致shard大小不均匀，按shard大小rollover确保每个shard都在50GB以内，避免巨型shard导致的恢复缓慢和查询性能下降。

forceMerge到1个segment后，索引不再支持写入（因为merge是不可逆操作）。如果业务需要回补历史数据，应在forceMerge之前完成。freeze动作在ES 8.x中已标记为废弃（frozen tier不再推荐），建议使用Searchable Snapshot替代：将cold数据快照到对象存储，按需挂载查询，节省本地存储成本。

冷热数据分层的业务需求

日志和时序数据的访问特征天然呈冷热分布：最近7天的数据查询频繁，30天前的数据偶尔检索，90天前的数据极少访问但需合规保留。将所有数据存储在相同配置的节点上，既造成SSD资源浪费，又无法满足长期数据的低成本存储需求。Elasticsearch的索引生命周期管理（Index Lifecycle Management，ILM）配合冷热数据分层架构，可以实现数据自动在不同层级的节点间迁移，兼顾查询性能与存储成本。

ILM策略配置与阶段详解

ILM策略定义索引在四个阶段的行为：Hot（热）、Warm（温）、Cold（冷）、Delete（删除）。每个阶段可指定触发条件和执行动作。

PUT _ilm/policy/logs-policy{  "policy": {    "phases": {      "hot": {        "min_age": "0ms",        "actions": {          "rollover": {            "max_primary_shard_size": "50gb",            "max_age": "1d",            "max_docs": 100000000          },          "set_priority": { "priority": 100 }        }      },      "warm": {        "min_age": "7d",        "actions": {          "shrink": { "number_of_shards": 1 },          "forcemerge": { "max_num_segments": 1 },          "allocate": {            "require": { "data": "warm" }          },          "set_priority": { "priority": 50 },          "readonly": {}        }      },      "cold": {        "min_age": "30d",        "actions": {          "allocate": {            "require": { "data": "cold" }          },          "set_priority": { "priority": 0 },          "freeze": {}        }      },      "delete": {        "min_age": "90d",        "actions": {          "delete": {}        }      }    }  }}

Hot阶段的rollover是核心动作，当索引的主分片大小超过50GB、索引年龄超过1天、或文档数超过1亿时，自动创建新索引并写入后续数据。Warm阶段执行shrink（缩减分片数）、forcemerge（强制合并段）和allocate（迁移到温节点）。Cold阶段迁移到冷节点并冻结索引，冻结后索引的FST和doc value卸载到磁盘，查询需先解冻。Delete阶段直接删除索引。

节点角色分配与冷热架构部署

冷热架构的核心是给节点打标签，通过ILM的allocate动作将索引路由到对应节点：

# Hot节点 - SSD，高性能node.roles: [data_hot]node.attr.data: hotpath.data: /data/ssd/elasticsearch# Warm节点 - HDD，中等性能node.roles: [data_warm]node.attr.data: warmpath.data: /data/hdd/elasticsearch# Cold节点 - 大容量HDD或对象存储node.roles: [data_cold]node.attr.data: coldpath.data: /data/hdd/elasticsearchnode.attr.data_cold: true

Elasticsearch 7.9+引入了data_tier角色（data_hot、data_warm、data_cold），自动处理节点属性的设置，比手动配置node.attr更可靠。部署时建议Hot节点使用NVMe SSD、Warm节点使用SATA SSD或高转速HDD、Cold节点使用大容量HDD或对象存储。

索引模板绑定ILM策略：

PUT _index_template/logs-template{  "index_patterns": ["logs-*"],  "template": {    "settings": {      "index.lifecycle.name": "logs-policy",      "index.lifecycle.rollover_alias": "logs",      "index.number_of_shards": 3,      "index.number_of_replicas": 1,      "index.routing.allocation.require.data": "hot"    },    "mappings": {      "properties": {        "timestamp": { "type": "date" },        "level": { "type": "keyword" },        "message": { "type": "text" },        "service": { "type": "keyword" }      }    }  }}

可搜索快照与对象存储集成

可搜索快照（Searchable Snapshot）是冷数据层的关键技术，允许直接从对象存储（S3、MinIO等）查询数据，无需先恢复到本地磁盘：

PUT _snapshot/cold-s3{  "type": "s3",  "settings": {    "bucket": "elasticsearch-cold",    "region": "us-east-1",    "base_path": "snapshots",    "server_side_encryption": true  }}// Cold阶段使用可搜索快照替代freeze"cold": {  "min_age": "30d",  "actions": {    "searchable_snapshot": {      "snapshot_repository": "cold-s3"    },    "set_priority": { "priority": 0 }  }}

可搜索快照在本地维护元数据缓存和部分热数据的缓存，实际查询时按需从S3拉取数据块。首次查询延迟较高（S3读取延迟约100ms），重复查询命中缓存后性能接近本地HDD。对于合规要求保留1年以上的日志数据，可搜索快照的存储成本仅为本地HDD的1/10。

ILM运维监控与常见问题

ILM执行状态可通过API实时监控：

// 查看索引的ILM状态GET logs-000001/_ilm/explain// 查看ILM策略执行进度GET _ilm/explain// 手步推进索引到下一阶段POST logs-000001/_ilm/retry// 常见问题排查// 1. 检查索引是否匹配模板中的index_patterns// 2. 确认ILM策略存在// 3. 查看是否有错误GET _ilm/explain?only_errors=true// 4. 检查节点属性与allocate的require是否匹配// 5. 确认集群有足够的热/温/冷节点接收迁移

常见故障及处理：rollover后新索引未继承ILM策略，通常是因为索引模板优先级问题；shrink操作失败多因目标分片数不是当前分片数的因子；Cold节点容量不足时ILM会暂停迁移并记录错误，需扩容或调整min_age延长迁移周期。建议在Grafana中配置ILM相关指标监控，重点关注ilm_phase转换延迟和shrink/forcemerge操作耗时。