Elasticsearch索引生命周期管理与冷热分层存储策略

Elasticsearch索引生命周期管理（ILM）是自动化管理索引从创建到删除全流程的机制，涵盖滚动更新、收缩、强制合并、冻结和删除等阶段。日志类应用每天产生大量索引，不加以管理会导致磁盘耗尽和查询性能退化。冷热分层架构将活跃索引放在高性能SSD节点（热节点），历史索引迁移到廉价HDD节点（冷节点），在控制成本的同时保持近期数据的高性能查询。

ILM策略定义与阶段配置

ILM通过policy定义索引的生命周期阶段，每个阶段执行特定操作。典型的日志索引生命周期分为hot、warm、cold、delete四个阶段。

PUT _ilm/policy/logs_lifecycle_policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_age": "1d",
            "max_primary_shard_size": "30gb",
            "max_docs": 50000000
          },
          "set_priority": {
            "priority": 100
          }
        }
      },
      "warm": {
        "min_age": "3d",
        "actions": {
          "shrink": {
            "number_of_shards": 1
          },
          "forcemerge": {
            "max_num_segments": 1
          },
          "allocate": {
            "include": {
              "data": "warm"
            }
          },
          "set_priority": {
            "priority": 50
          }
        }
      },
      "cold": {
        "min_age": "14d",
        "actions": {
          "freeze": {},
          "allocate": {
            "include": {
              "data": "cold"
            }
          },
          "set_priority": {
            "priority": 10
          }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {
            "delete_searchable_snapshot": true
          }
        }
      }
    }
  }
}

各阶段作用说明：hot阶段设定rollover条件，达到任一阈值（1天/30GB/5000万文档）时滚动创建新索引。warm阶段将索引从热节点迁移到温节点，同时执行shrink减少分片数和forcemerge合并段文件，降低资源占用。cold阶段冻结索引（freeze），从堆内存卸载到磁盘，仅查询时按需加载。delete阶段在90天后永久删除索引。

索引模板与别名绑定

ILM策略需要通过索引模板应用到新创建的索引。使用别名（alias）作为写入和查询的统一入口，rollover时自动切换别名指向新索引。

PUT _index_template/logs_template
{
  "index_patterns": ["logs-app-*"],
  "template": {
    "settings": {
      "index.lifecycle.name": "logs_lifecycle_policy",
      "index.lifecycle.rollover_alias": "logs-app-write",
      "number_of_shards": 5,
      "number_of_replicas": 1,
      "refresh_interval": "5s",
      "index.routing.allocation.include.data": "hot"
    },
    "mappings": {
      "properties": {
        "@timestamp": { "type": "date" },
        "level": { "type": "keyword" },
        "service": { "type": "keyword" },
        "message": { "type": "text" },
        "host": { "type": "keyword" },
        "trace_id": { "type": "keyword" }
      }
    }
  },
  "priority": 100
}

初始化第一个索引并绑定写入别名：

# 创建初始索引（必须以000001结尾）
PUT logs-app-000001
{
  "aliases": {
    "logs-app-write": {
      "is_write_index": true
    },
    "logs-app-read": {}
  }
}

# 应用写入数据到别名，非索引名
POST logs-app-write/_doc
{
  "@timestamp": "2026-08-11T10:00:00Z",
  "level": "INFO",
  "service": "api-gateway",
  "message": "Request processed in 45ms",
  "host": "node-01",
  "trace_id": "a1b2c3d4"
}

rollover触发后，新索引logs-app-000002自动创建并成为写入索引。读取别名logs-app-read始终保持指向所有活跃索引，应用程序无感知。

节点角色与冷热分层架构

冷热分层依赖Elasticsearch的节点角色（node.roles）配置。热节点使用SSD承担写入和近期查询，温节点使用普通SSD承担历史查询，冷节点使用大容量HDD承担归档查询。

# elasticsearch.yml - 热节点（高性能SSD）
node.roles: [data_hot, data_content, ingest]
cluster.routing.allocation.disk.watermark.low: 85%
cluster.routing.allocation.disk.watermark.high: 90%

# 温节点（标准SSD）
node.roles: [data_warm, data_content]

# 冷节点（大容量HDD）
node.roles: [data_cold, data_content]
cluster.routing.allocation.disk.watermark.low: 90%

# 冻结节点（专用于搜索冻结索引）
node.roles: [data_frozen]

节点配置完成后，通过_cluster/settings确认节点角色分配：

GET _cat/nodeattrs?v&h=node,attr,value&attr=data

# 输出示例:
# node-01 data hot
# node-02 data hot
# node-03 data warm
# node-04 data warm
# node-05 data cold
# node-06 data cold

磁盘容量规划的经验值：热节点存储约3天数据，占总数据量的5%但承担100%的写入和大部分查询。温节点存储4-11天数据，占总量的20%。冷节点存储12-90天数据，占总量的75%。按此比例配置节点数量和磁盘大小。

ILM执行监控与故障排查

ILM策略执行状态可通过专用API查询：

# 查看所有索引的ILM状态
GET logs-app-*/_ilm/explain

# 输出示例:
# {
#   "indices": {
#     "logs-app-000001": {
#       "index": "logs-app-000001",
#       "managed": true,
#       "policy": "logs_lifecycle_policy",
#       "lifecycle_date_millis": 1723353600000,
#       "age": "3d",
#       "phase": "warm",
#       "phase_time_millis": 1723612800000,
#       "action": "shrink",
#       "step": "SUCCESS",
#       "step_time_millis": 1723612860000
#     }
#   }
# }

# 查看特定索引的ILM详情
GET logs-app-000003/_ilm/explain

# 查看ILM执行错误
GET _ilm/explain?filter_path=*.**.step_info
# step_info字段包含错误信息

ILM执行卡住的常见原因及处理方法：

# 原因1：分片分配失败（节点磁盘满或无符合条件的节点）
# 检查分片分配解释
GET _cluster/allocation/explain
{
  "index": "logs-app-000005",
  "shard": 0,
  "primary": true
}

# 原因2：shrink操作要求源索引所有分片在同一节点
# 检查分片分布
GET _cat/shards/logs-app-000005?v&h=index,shard,node

# 手动触发分片重分配
POST logs-app-000005/_cluster/reroute
{
  "commands": [
    {
      "allocate_stale_primary": {
        "index": "logs-app-000005",
        "shard": 0,
        "node": "node-03",
        "accept_data_loss": false
      }
    }
  ]
}

# 原因3：ILM服务暂停
# 检查ILM状态
GET _ilm/status
# 若status为stopped，重新启动
POST _ilm/start

# 手动重试失败的步骤
POST logs-app-000005/_ilm/retry

生产环境中建议配置监控告警，当ILM策略执行失败或分片分配异常时及时通知。配合Curator或ES内置的Data Rollup功能对历史数据做聚合降采样，进一步降低存储和查询压力。冻结索引的查询延迟较高（秒级），对实时性要求高的报表应限定查询热和温节点上的索引。