4. Elasticsearch 索引生命周期管理：ILM 策略设计

在 Golden Signals 日志检索工程中，日志数据具有时间序列强、冷热访问差异大、保留周期明确三大特征。Elasticsearch 索引生命周期管理（ILM）正是应对这些特征的核心工具。通过 ILM，我们可以按时间与信号类型自动分索引，在查询性能与存储成本之间取得最优平衡。

4.1 ILM 四阶段模型与 Golden Signals 映射

ILM 标准阶段包括 Hot → Warm → Cold → Delete。针对 Golden Signals 日志，每个阶段的存储介质、副本数、分段合并策略均不同：

4.2 按信号类型拆分索引模板

每个 Golden Signals 维度对应一个独立的索引模板，确保字段映射、分片数、滚动策略互不干扰：

# 延迟信号索引模板
PUT _index_template/gs-latency-template
{
  "index_patterns": ["gs-latency-*"],
  "template": {
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1,
      "index.lifecycle.name": "gs-latency-policy",
      "index.lifecycle.rollover_alias": "gs-latency-write"
    },
    "mappings": {
      "properties": {
        "@timestamp":    { "type": "date" },
        "service":       { "type": "keyword" },
        "latency_ms":    { "type": "long" },
        "percentile_99": { "type": "float" },
        "host":          { "type": "keyword" }
      }
    }
  }
}

# 错误信号索引模板
PUT _index_template/gs-error-template
{
  "index_patterns": ["gs-error-*"],
  "template": {
    "settings": {
      "number_of_shards": 5,
      "number_of_replicas": 1,
      "index.lifecycle.name": "gs-error-policy",
      "index.lifecycle.rollover_alias": "gs-error-write"
    },
    "mappings": {
      "properties": {
        "@timestamp":    { "type": "date" },
        "service":       { "type": "keyword" },
        "error_code":    { "type": "keyword" },
        "stack_trace":   { "type": "text", "index": false },
        "severity":      { "type": "keyword" }
      }
    }
  }
}

4.3 ILM 策略完整配置示例

以下策略针对延迟信号设计，展示 Hot → Warm → Cold → Delete 的完整参数：

PUT _ilm/policy/gs-latency-policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_size": "50GB",
            "max_age": "6h"
          },
          "set_priority": {
            "priority": 100
          }
        }
      },
      "warm": {
        "min_age": "6h",
        "actions": {
          "forcemerge": {
            "max_num_segments": 1
          },
          "shrink": {
            "number_of_shards": 1
          },
          "allocate": {
            "number_of_replicas": 1,
            "require": {
              "data_type": "warm"
            }
          },
          "set_priority": {
            "priority": 50
          }
        }
      },
      "cold": {
        "min_age": "7d",
        "actions": {
          "allocate": {
            "number_of_replicas": 0,
            "require": {
              "data_type": "cold"
            }
          },
          "set_priority": {
            "priority": 0
          }
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

4.4 按时间与信号类型分索引的架构流程

下图展示从日志采集到 ILM 自动流转的完整链路：

4.5 查询与存储成本优化策略

通过 ILM 分索引后，还需配合以下手段进一步优化：

• 按时间范围路由查询：在 Kibana 或 API 查询中强制指定 @timestamp 范围，ES 自动跳过不相关的索引，减少分片扫描。
• 使用索引别名分离读写：写别名指向 Hot 索引，读别名指向 Hot+Warm+Cold 所有索引，避免业务侧感知索引名变化。
• Warm 阶段 forcemerge 到 1 段：减少分段数量可降低内存开销，同时提升只读查询性能。
• Cold 阶段副本数设为 0：归档数据不再需要高可用，节省 50% 存储成本。
• 信号类型差异化保留周期：

4.6 监控 ILM 执行状态

部署完成后，通过以下 API 和指标持续观察 ILM 健康度：

# 查看所有索引的 ILM 阶段
GET _ilm/status

# 查看具体索引的 ILM 执行详情
GET gs-latency-2025-04-01-000001/_ilm/explain

# 关键监控指标（Grafana / Kibana 看板）
- ilm.time-since-index-rollover    # 距离上次滚动的时间
- ilm.number-of-errors             # ILM 执行错误数
- indices.lifecycle.completed      # 已完成生命周期管理的索引数
- node.data_type                   # 各存储层节点的磁盘使用率