4、日志存储与管理：集中式日志存储（ELK、Loki）、日志生命周期管理、数据保留策略与合规

日志存好了，才谈得上分析。这个道理我早年吃过亏才真正明白。

那时候我负责一个AI模型的线上监控，日志散落在各个服务器上。出了安全问题，我得一台一台登录去翻，经常翻到凌晨两三点。后来我痛定思痛，把所有日志都集中起来。嗯，今天我们就聊聊集中式日志存储这件事。

4.1 集中式日志存储：ELK 与 Loki

集中式存储，说白了就是把分散的日志收拢到一个地方。我个人习惯用ELK，但Loki在某些场景下也很香。

4.1.1 ELK 技术栈

ELK是Elasticsearch、Logstash、Kibana的缩写。我在项目中遇到过很多团队把这套玩得很溜。

• Elasticsearch：负责存储和搜索。它是个分布式搜索引擎，能扛住海量日志。
• Logstash：负责采集和加工。它可以把不同格式的日志解析成统一结构。
• Kibana：负责可视化和告警。你可以在上面画图表、设规则。

举个例子，我们当时要审计AI模型的请求日志。每条日志包含用户ID、请求时间、模型版本、返回结果。用Logstash配置一个解析规则，几行代码就搞定了：

input {
  file {
    path => "/var/log/ai_model/*.log"
    start_position => "beginning"
  }
}

filter {
  grok {
    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{DATA:user_id} %{DATA:model_version} %{GREEDYDATA:response}" }
  }
}

output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "ai-model-logs-%{+YYYY.MM.dd}"
  }
}

这样配置完，所有日志自动进入Elasticsearch。你想想看，以前要花半小时查的东西，现在Kibana里搜一下，几秒钟就出来了。

4.1.2 Loki 技术栈

Loki是Grafana团队推出的日志系统。它和ELK最大的区别是什么？Loki不建立全文索引，它只索引日志的元数据（比如标签）。

为什么会这样？因为ELK的全文索引虽然搜索快，但存储成本高。Loki的做法是：把日志压缩存储，搜索时再扫描。说白了，就是用计算换存储。

我在项目中遇到过这样一个场景：我们只需要按服务名和时间范围查日志，不需要全文搜索。这时候Loki就特别合适。它的配置也简单：

scrape_configs:
  - job_name: ai_model_logs
    static_configs:
      - targets: [localhost]
        labels:
          job: ai_model
          __path__: /var/log/ai_model/*.log

然后配合Grafana，直接就能查。嗯，这里要注意：如果你的日志需要频繁做全文搜索，还是老老实实用ELK吧。

4.2 日志生命周期管理

日志不是存得越久越好。我见过一个团队，日志存了三年，结果磁盘爆了，整个系统都崩了。你想想看，这多冤。

日志生命周期管理，就是给日志定一个「生老病死」的规则。我个人习惯分三个阶段：

• 热阶段：最近7天的日志。存在SSD上，查询速度要快。
• 温阶段：7天到3个月的日志。存在普通硬盘上，偶尔查。
• 冷阶段：3个月以上的日志。压缩后存到对象存储（比如S3），几乎不查，但合规要求必须保留。

在ELK中，我们可以用索引生命周期管理（ILM）来实现：

PUT _ilm/policy/ai_model_logs_policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_size": "50GB",
            "max_age": "7d"
          }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "allocate": {
            "require": {
              "data_type": "warm"
            }
          }
        }
      },
      "cold": {
        "min_age": "90d",
        "actions": {
          "freeze": {}
        }
      },
      "delete": {
        "min_age": "365d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

4.3 数据保留策略与合规

合规是个大问题。不同行业、不同地区对日志保留时间的要求不一样。比如金融行业，通常要求保留至少3年。GDPR则要求个人数据不能无限期保留。

我建议你这样做：

• 明确合规要求：先搞清楚你们行业的规定。比如PCI DSS要求日志保留至少1年，HIPAA要求6年。
• 分类分级：不是所有日志都一样重要。安全审计日志要保留更久，调试日志可以短一些。
• 自动化删除：别手动删，容易出错。用ILM或Loki的保留策略自动处理。

举个例子，对于AI模型的请求日志，我们当时是这样设计的：

嗯，最后说一句。日志存储和管理，看似是技术活，其实更是管理活。你不仅要懂ELK、Loki，还要懂合规、懂业务。我这些年最大的体会就是：别等出了事再想怎么存日志，提前规划好，后面能省很多麻烦。