3. 日志存储与管理：存储选型、生命周期与冷热分层

日志存哪儿、存多久、怎么管，是审计日志落地时最容易被低估的环节。我见过不少团队，前期把精力全扑在采集和告警上，结果三个月后存储爆了，查个历史日志要等半小时。说白了，存储选型不是技术炫技，是成本与查询效率的平衡。

3.1 存储选型：三大主流方案怎么挑？

目前业界主流的审计日志存储方案，基本就是 Elasticsearch、S3 和 HDFS 三足鼎立。它们各有各的脾气，选错了后面会很痛苦。

特性	Elasticsearch	S3（对象存储）	HDFS
查询能力	全文检索、聚合分析、实时	弱，需配合 Athena 等	弱，需配合 Hive/Spark
写入吞吐	中等，受分片数限制	极高，可无限扩展	高，适合批量写入
存储成本	高（副本+索引开销）	低（按量付费）	中等（依赖本地盘）
适用场景	近实时检索、安全分析	长期归档、冷数据	离线批处理、数仓

3.2 生命周期管理：日志不是越久越好

审计日志有合规要求，但合规不等于无限保留。PCI DSS 要求保留 1 年，SOC 2 要求 6 个月，GDPR 甚至要求某些数据到期必须删除。你想想看，如果所有日志都存 3 年，Elasticsearch 集群早就撑爆了。

我建议按以下策略管理生命周期：

• 热数据（0-7 天）： 保留在 Elasticsearch，SSD 存储，副本数 2，用于实时告警和调查。
• 温数据（7-90 天）： 迁移到 Elasticsearch 冷节点或 S3 Standard，HDD 存储，副本数 1，用于月度审计。
• 冷数据（90 天 - 1 年）： 归档到 S3 Glacier 或 HDFS，压缩存储，查询时需解冻。
• 过期数据（超过保留期）： 彻底删除，避免合规风险。

3.3 冷热分层架构：一张图看懂

冷热分层不是新概念，但在审计日志场景下特别实用。下面这张图展示了我常用的分层架构：

这个架构的核心思路是：数据自动流动，查询按需取用。热层负责快速写入和实时查询，温层做月度审计，冷层只用于合规归档。你不需要手动搬数据，ILM 和 S3 Lifecycle 策略会自动处理。

3.4 数据保留策略：合规与成本的博弈

保留策略不是拍脑袋定的。我一般会先问三个问题：

1. 合规要求是什么？ 金融行业通常要求保留 3-7 年，互联网公司可能只要 6 个月。
2. 查询频率有多高？ 如果每月只查一次，没必要放热层。
3. 预算有多少？ Elasticsearch 的存储成本是 S3 的 5-10 倍。

下面是我常用的保留策略模板，你可以根据实际情况调整：

数据层级	存储介质	保留时长	查询延迟	月成本（1TB）
热	Elasticsearch SSD	7 天	< 1 秒	~$300
温	S3 Standard	90 天	几秒	~$25
冷	S3 Glacier Deep Archive	1 年+	12 小时	~$1

3.5 实战：Elasticsearch ILM 配置示例

光说不练假把式。下面是我在一个金融项目中用过的 ILM 策略，你可以直接参考：

PUT _ilm/policy/audit_log_policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_size": "50GB",
            "max_age": "7d"
          },
          "set_priority": {
            "priority": 100
          }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "shrink": {
            "number_of_shards": 1
          },
          "forcemerge": {
            "max_num_segments": 1
          },
          "set_priority": {
            "priority": 50
          }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "freeze": {},
          "set_priority": {
            "priority": 0
          }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

这个策略的意思是：索引在热节点存 7 天或 50GB，然后自动滚到温节点，30 天后冻结为冷索引，90 天后自动删除。你只需要在索引模板里引用这个策略就行。