Elasticsearch 日志索引设计：按小时切分 + 小时内 Rollover 兜底（ILM 实战，附完整脚本）

Elasticsearch 日志索引设计：按小时切分 + 小时内 Rollover 兜底（ILM 实战，附完整脚本）

日志场景下 Elasticsearch 索引怎么切？按天建索引，大流量日单索引轻松突破几百 GB，merge 变慢、查询抖动；只靠 ILM 按大小 rollover，索引边界又和业务时间对不上，排障时想拉某个小时的日志都费劲。本文给出一套外层按整点小时切分 + 内层 Rollover 兜底的双层别名方案，ILM 策略、索引模板、cron 脚本、应用层写入路由全部可复制。

一、为什么日志索引推荐按小时切分

先看两种常见做法的坑：

日志数据有强时间特征：排查看小时、对账按小时、归档删过期也按时间。所以理想方案是索引边界严格对齐整点小时，同时在单小时数据突增时还能自动拆分——这就是双层设计。

二、方案总览：双层别名架构

• 外层（小时级）：每整点由 cron 新建一个独立索引，名字带小时戳
• 内层（rollover 级）：同一小时内数据量超阈值时自动 rollover 出新物理索引
• 双层 alias：外层别名按小时命名，承载写入和查询；内层 rollover 由 ILM 维护

logs-2026061114-000001 ─┐
logs-2026061114-000002 ─┼─ alias: logs-2026061114 (is_write_index: 当前可写)
logs-2026061115-000001 ──── alias: logs-2026061115 (is_write_index: 当前可写)

应用层只认 logs-YYYYMMDDHH 这个小时级别名，rollover 发生时别名自动切换，写入方零改动。

需要的资源一共 5 项：

三、部署步骤

3.1 创建 ILM 策略（全集群一份）

PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "20gb",
            "max_docs": 100000000
          }
        }
      },
      "warm": {
        "min_age": "3d",
        "actions": {
          "forcemerge": { "max_num_segments": 1 }
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": { "delete": {} }
      }
    }
  }
}

阶段说明：

• hot：可写阶段，单索引到 20GB 或 1 亿文档即 rollover，防止索引过大
• warm：3 天后强制段合并为 1 段，省存储、提查询
• delete：30 天后自动删除

⚠️ 不要配 max_age。整点切索引已经承担了时间维度的切分，ILM 里再配 max_age 会和小时边界冲突，出现"不到整点就滚"的脏边界。

3.2 创建索引模板

PUT _index_template/logs-template
{
  "index_patterns": ["logs-*"],
  "priority": 100,
  "template": {
    "settings": {
      "number_of_shards": 10,
      "number_of_replicas": 1
    },
    "mappings": {
      "properties": {
        "@timestamp": { "type": "date" },
        "level":      { "type": "keyword" },
        "message":    { "type": "text" },
        "service":    { "type": "keyword" },
        "host":       { "type": "keyword" }
      }
    }
  }
}

注：mappings 按实际日志字段补充。ILM 绑定和 rollover_alias 不要写在模板里，留到每小时的种子索引上单独指定，避免污染所有 logs-* 索引。

3.3 Cron 脚本：每整点创建种子索引

脚本路径 /opt/scripts/create_hourly_index.sh：

#!/bin/bash
set -euo pipefail

ES_HOST="${ES_HOST:-http://es-host:9200}"
HOUR=$(date -u +%Y%m%d%H)
INDEX="logs-${HOUR}-000001"
ALIAS="logs-${HOUR}"

# 幂等检查：索引已存在则跳过
STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
  -u "${ES_USER}:${ES_PASS}" \
  -X HEAD "${ES_HOST}/${INDEX}")

if [ "$STATUS" = "200" ]; then
  echo "[$(date)] Index ${INDEX} already exists, skip."
  exit 0
fi

if [ "$STATUS" != "404" ]; then
  echo "[$(date)] Unexpected status ${STATUS} for ${INDEX}, abort."
  exit 1
fi

# 创建种子索引，同时挂外层 alias 和 ILM 配置
RESP=$(curl -s -u "${ES_USER}:${ES_PASS}" \
  -X PUT "${ES_HOST}/${INDEX}" \
  -H 'Content-Type: application/json' \
  -d "{
    \"aliases\": {
      \"${ALIAS}\": { \"is_write_index\": true }
    },
    \"settings\": {
      \"index.lifecycle.name\": \"logs-policy\",
      \"index.lifecycle.rollover_alias\": \"${ALIAS}\"
    }
  }")

echo "[$(date)] Create ${INDEX} alias ${ALIAS}: ${RESP}"

crontab 配置：

# 每小时 0 分 5 秒执行（避开整点集群压力尖峰）
5 * * * * /opt/scripts/create_hourly_index.sh >> /var/log/es-hourly-index.log 2>&1

两个细节：脚本里 date -u 用 UTC，全链路统一时区；crontab 建议主备双机部署，防止单点漏建。

四、应用层接入

4.1 写入路由：按当前小时选别名

Java 示例：

String hour = ZonedDateTime.now(ZoneOffset.UTC)
    .format(DateTimeFormatter.ofPattern("yyyyMMddHH"));
String alias = "logs-" + hour;

IndexRequest req = new IndexRequest(alias)
    .source(jsonMap, XContentType.JSON);

Python 示例：

from datetime import datetime, timezone

def current_alias():
    hour = datetime.now(timezone.utc).strftime("%Y%m%d%H")
    return f"logs-{hour}"

es.index(index=current_alias(), document=log_entry)

4.2 查询姿势

# 单小时查询
GET logs-2026061114/_search

# 跨小时：明确列出，别用通配符（展开慢）
GET logs-2026061113,logs-2026061114/_search

# 时间范围查询兜底
GET logs-*/_search
{
  "query": {
    "range": { "@timestamp": { "gte": "now-2h", "lte": "now" } }
  }
}

五、Rollover 行为详解

触发时机：小时内数据满足任一条件自动 rollover——单索引 ≥20GB，或文档数 ≥1 亿。

状态变化：

触发前:
  logs-2026061114-000001 ← 可写 (is_write_index: true)

触发后:
  logs-2026061114-000001 ← 只读
  logs-2026061114-000002 ← 可写 (is_write_index: true)

小时别名 logs-2026061114 自动指向 000002，应用层无感知。

与下个整点的衔接：

• 14:59:59 数据仍写入 logs-2026061114-000002
• 15:00:05 cron 执行，新建 logs-2026061115-000001
• 应用层下次写入按当前小时自动切到 logs-2026061115-*

六、验证与日常运维命令

# 查看某小时索引的 ILM 进度
GET logs-2026061114/_ilm/explain

# 查看别名当前指向
GET _alias/logs-2026061114

# 列出最近索引的大小与文档数
GET _cat/indices/logs-*?h=index,docs.count,store.size&s=index

测试时手动触发一次 rollover 验证链路：

POST logs-2026061114/_rollover
{
  "conditions": { "max_docs": 1 }
}

七、监控告警配置

监控建议接 Prometheus + ElastAlert 或自研 watcher，重点盯索引缺失——cron 失败意味着应用写入直接报错。

八、踩坑清单

九、部署 Checklist

• 创建 ILM policy logs-policy
• 创建 Index template logs-template
• 部署 create_hourly_index.sh 到独立调度机
• 配置 crontab（主备双机）
• 应用层改造写入路由逻辑
• 配置监控告警（缺失索引、ILM 卡住、磁盘）
• 测试环境完整跑一次 rollover 验证

十、版本兼容性

总结

这套方案的本质是让时间边界和数据量边界各管各的：整点切分满足排障、对账、归档的时间对齐需求，ILM rollover 兜住流量突增，双层别名把两者对应用层透明。全部资源就一份 ILM 策略 + 一份模板 + 一个 cron 脚本，复制文中 DSL 即可落地。

你们的日志索引是按天切、按小时切，还是纯 rollover？有没有遇到过单索引几百 GB 的场面？评论区聊聊你的切法。

文中脚本与 DSL 在 ES 7.17/8.x 环境验证通过，字段映射请按实际业务调整。