📚 课程目录第3章审计日志采集与存储

3. 审计日志采集与存储

日志采集和存储，是整个异常检测的“地基”。地基不牢，后面分析再漂亮也是空中楼阁。
这一节我会从工具选型、集中存储方案对比，到实战部署和避坑，一条线讲清楚。

3.1 日志采集的工具选型

采集工具有很多，但真正在生产环境里经得住考验的，其实就那几个。

3.1.1 Filebeat – 轻量级首选

我个人习惯先用 Filebeat。它基于 Go 开发，资源占用极低，适合部署在数据库服务器上。
曾经有个金融客户，要求采集 2000+ 台 MySQL 的审计日志，CPU 占用不能超过 2%。我果断选了 Filebeat，配合自定义多行处理规则，上线后监控显示平均 CPU 只增加了 1.3%，很稳。

3.1.2 Fluentd – 灵活的路由

如果你需要复杂的数据过滤和路由，Fluentd 更合适。它支持上千个插件，能把日志丢到 S3、Kafka、Elasticsearch 等。
不过要注意，Ruby 写的 Fluentd 在吞吐量超过 10 万条/秒时容易丢数据。我踩过这个坑，后来用 Fluent Bit（C 语言版）替换了采集端。

3.1.3 Logstash – 重量级处理器

Logstash 很强，但很重。它的好处是内置大量 filter 插件（grok、date、geoip 等），适合在存储前做数据清洗。

我建议：采集端用 Filebeat，清洗端用 Logstash，各司其职。

经验提示：
采集层的最大隐患是“日志丢失”。一定要启用 Filebeat 的 ack 确认机制，并配置 data 路径持久化，防止采集进程重启时丢数据。

3.2 集中存储方案概览

日志采集上来后，总得有个地方存放。目前主流方案就三种：ELK、Splunk、自研。
下表是我整理的对比，你一看就明白了。

维度	ELK（Elastic Stack）	Splunk	自研（Kafka+ES）
开源/付费	开源（商业版付费）	商业授权，价格高	全开源
部署复杂度	中等，组件多	简单，一体化安装	高，需自建 Kafka 集群
检索性能	秒级，支持聚合	极快，专用 SPL 语言	与 ELK 相当
安全审计能力	需额外的 Watcher / Alerting	原生告警，权限细粒度	完全自建
典型场景	中小企业，DevOps	金融、政府、合规严苛场景	大规模、极度定制化需求

说白了，Splunk 用钱换时间，ELK 用时间换钱。我个人更倾向 ELK，因为社区的生态和灵活性足够强。

3.3 ELK 实战部署要点

我之前参与的一个数据库审计项目，日志量每天 500GB。ELK 的部署踩了不少坑，这里把关键流程提炼出来。

3.3.1 架构选型：Filebeat → Kafka → Logstash → ES

直接 Filebeat → Logstash 在峰值流量时容易撑爆 Logstash 内存。我后来引入了 Kafka 作为缓冲层，就像给水管加了个蓄水池，流量再大也不会撑破。

# Filebeat 配置（output 指向 Kafka）
filebeat.inputs:
- type: log
  paths: /var/log/mysql/audit/*.log
  multiline.pattern: '^\d{4}-\d{2}-\d{2}'
  multiline.negate: true
  multiline.match: after

output.kafka:
  hosts: ["kafka1:9092", "kafka2:9092"]
  topic: "audit-log"

3.3.2 Logstash 配置：数据清洗与字段映射

审计日志通常有固定格式，比如 MySQL audit 的 JSON 格式。用 grok 解析后，再统一字段名，方便后续分析。

input {
  kafka { bootstrap_servers => "kafka1:9092"; topics => ["audit-log"] }
}
filter {
  if [message] =~ /^\{/ {
    json { source => "message"; target => "audit_event" }
  }
  mutate {
    rename => { "[audit_event][user]" => "user_name" }
  }
}
output {
  elasticsearch {
    hosts => ["http://es-cluster:9200"]
    index => "audit-%{+YYYY.MM.dd}"
  }
}

3.3.3 Elasticsearch 索引优化

日志类数据一定要开 索引生命周期管理（ILM）。我记得有一次没配 ILM，一个月后 ES 磁盘爆满，集群直接挂了。教训惨痛。

PUT _ilm/policy/audit_policy
{
  "policy": {
    "phases": {
      "hot":  { "min_age": "0d", "actions": { "rollover": { "max_size": "50GB" } } },
      "delete": { "min_age": "30d", "actions": { "delete": {} } }
    }
  }
}

避坑指南：
我曾经因为节点数不够，导致 ES 写入反压严重，日志堆积在 Kafka 里。Kafka 磁盘写满后，整个生产链路都炸了。
嗯，这里要注意：Kafka 的日志保留时间要设置得足够长（比如 7 天），并且监控消费者消费延迟。

3.4 存储优化与安全考虑

3.4.1 存储瘦身：采样与聚合

审计日志里 90% 是正常操作，只有 10% 需要重点分析。你可以对正常操作做采样，只保留异常的完整记录。
我习惯在 Logstash 里用 drop 插件配合条件判断，比如“只保留 SQL 执行时间 > 10s 或用户是 root 的记录”。这样存储量直接降一个量级。

3.4.2 安全与权限

审计日志本身就是敏感数据。Elasticsearch 一定要开启 X-Pack 安全功能，限制只有 DBA 和安全人员能访问。
另外，日志传输链路要加密。Filebeat → Kafka 用 SSL，Kafka → Logstash 也用 SASL。我曾经在客户现场发现他们日志明文传输，吓得我连夜帮他们加了 TLS。

核心原则：

采集层要轻（Filebeat）、缓冲层要稳（Kafka）、存储层要快（ES）、安全层要严（加密+权限）。缺一个，后期都会出事。

3.5 整体流程架构

下面这张图，把审计日志从产生到落地的完整链路画出来了。你可以把它当作你设计存储方案的“参考蓝本”。

你看，整个链路从数据库产生日志，采集端用 Filebeat 或 Fluentd，经过 Kafka 削峰填谷，到 Logstash 清洗，最后存入 Elasticsearch，Kibana 负责可视化分析。
至于 Splunk？图中我画了一条虚线：它可以直接替换整个 ELK 部分，但代价是钱。

3.6 小结

这一节我讲了工具选型、方案对比、实战部署和存储安全。说白了，日志采集没有银弹，但只要你遵循“轻采集、稳缓冲、快存储、严安全”的套路，基本不会出大格。
哦对，还有一点：别忘了给日志打时间戳。没有时间序的审计日志，就像没有标尺的尺子，毫无价值。