审计日志采集与存储：集中式日志收集架构

日志采集这件事，看着简单，做起来坑不少。我早年在一个金融项目里，服务器就上百台，每天日志量几个TB。刚开始各项目组自己管自己的日志，出问题要查，得挨个服务器登录，效率低到让人崩溃。嗯，所以集中式日志收集架构，说白了就是给日志找个统一的家。

这个章节，我重点聊聊目前最主流的两个方案：ELK和Splunk。一个开源免费，一个商业强大。怎么选？咱们得看场景。

为什么需要集中式日志收集？

你想想看，没有集中的时候，问题在哪？

  • 日志分散：应用、系统、网络设备，各自为政。
  • 格式不统一：有的是JSON，有的是纯文本，有的是syslog。
  • 查询困难：用grep、awk在100台机器上找关键词？想想就头疼。
  • 存储压力：历史日志占空间，删了又怕需要回溯。

一句话总结：集中式收集不是锦上添花，而是安全运维的生命线。没有统一视图，异常检测就是空谈。

ELK Stack：开源界的扛把子

ELK是Elasticsearch、Logstash、Kibana这三个核心组件的简称。我个人习惯叫它“全家桶”，因为现在还有Beats、Kafka等一堆好用的兄弟加入。

核心组件与职责

组件 角色 通俗理解
Beats 轻量级采集器 装在每台服务器上，负责把日志“叼”出来，比如Filebeat读文件，Metricbeat采指标。
Logstash 数据处理管道 接收日志，做过滤、解析、格式化，再吐给Elasticsearch。像个“清洁工”加“分类员”。
Elasticsearch 分布式搜索与分析引擎 存数据，提供近乎实时的搜索和聚合。日志进来后按索引存储，方便你快速查找。
Kibana 可视化与Dashboard 把数据变成图表。我做安全分析最常用的就是Kibana的图表和告警规则。

避坑指南：我曾经在ELK架构里直接让Filebeat发数据给Logstash，结果Logstash一挂，所有日志全丢。后来我加了Kafka做消息队列缓冲，稳如狗。

一个典型的ELK采集流水线配置

这是我在项目中常用的一套入门配置。先用Filebeat收集系统auth.log：

# filebeat.yml
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/auth.log
  fields:
    log_type: security

output.kafka:
  hosts: ["kafka-01:9092", "kafka-02:9092"]
  topic: "security-events"

然后Logstash从Kafka消费并解析：

# logstash.conf
input {
  kafka {
    bootstrap_servers => "kafka-01:9092,kafka-02:9092"
    topics => ["security-events"]
    codec => "json"
  }
}

filter {
  grok {
    match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:hostname} %{DATA:process}\[%{NUMBER:pid}\]: %{GREEDYDATA:log_message}" }
  }
  date {
    match => [ "timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
  }
}

output {
  elasticsearch {
    hosts => ["http://elasticsearch-01:9200"]
    index => "auth-logs-%{+YYYY.MM.dd}"
  }
}

注意：如果日志量一天超过10GB，建议你一定要引入Kafka或RabbitMQ。否则Logstash处理压力一大，直接OOM，整个链路都会断。

Splunk：企业级的安全运维利器

Splunk是商业软件，功能强大，但价格也不便宜。为什么还要用？

说实话，我在甲方公司推Splunk的时候，一开始是抗拒的。毕竟ELK开源免费，谁不想要白嫖？但真正用起来才发现，Splunk在安全运维场景下有几个不可替代的优势：

  • SPL查询语言：强大到令人发指。查找某个IP在过去24小时的所有失败登录，一行搞定。
  • 机器学习工具包：内置异常检测算法，做基线化的成本低很多。
  • 数据治理：RBAC、数据脱敏、审计日志本身的安全性，做得非常成熟。

架构对比：ELK vs Splunk

维度 ELK Stack Splunk
许可 开源（部分功能需付费） 商业，按日或按存储量收费
上手难度 中高（需要自己调优） 低（企业级支持好）
日志解析 依赖Grok/Filter配置 自动解析，支持自定义规则
告警能力 通过ElastAlert/Watcher 内置告警引擎，集成度高
适合场景 预算有限、团队有运维能力 企业安全运营、合规要求高

我的个人经验：如果团队小于5个人，用ELK完全够；如果团队大、安全合规要求强，建议直接上Splunk。别想着省钱，出一次安全事件就什么都回来了。

集中式日志收集的核心架构图

下面这张图是我总结的经典架构。你想想看，它把日志从源头到存储再到分析，串成了一条清晰的流水线。

集中式日志收集架构总览 日志源 应用服务器 网络安全设备 采集层 Filebeat / Beats Syslog / Agent 消息队列 Kafka RabbitMQ 处理/解析层 Logstash Filter / Grok 存储与索引 Elasticsearch Splunk Indexer 分析呈现 Kibana Splunk Dashboard 注：ELK与Splunk在上述分层中角色类似，只是具体组件命名不同

存储选型与容量规划

日志存多久？用什么存？这块我吃过亏。之前有个项目，日志全都存在Elasticsearch里，没做冷热分层。结果半年后，几百TB的磁盘差点把机房给撑爆了。

常见的分层存储策略

  • 热数据：最近7天，SSD存储，保持高查询性能。用于日常安全监控。
  • 温数据：7天到3个月，HDD存储，压缩比高。用于回溯分析。
  • 冷数据：3个月以上，归档到S3或HDFS，甚至直接压缩备份。用于合规审计。

容量估算小技巧：日均日志量 × 保留天数 × 1.5（冗余系数）= 所需存储空间。比如每天100GB，保留90天，大致需要13.5TB。

我曾经犯过一个错：没有给存储预留IOPS。当大量日志写入时，查询响应直接慢成幻灯片。所以存储选型时，别只看容量，还要看每秒写入能力。

小结

审计日志采集与存储，是整个异常检测体系的基石。说白了，没有高效可靠的收集管道，后续的分析、告警、复盘都是空中楼阁。

ELK适合开源爱好者、有运维能力的团队；Splunk适合追求效率、对合规要求严格的组织。但不管选哪个，架构设计都得考虑缓存（Kafka）、分层存储、以及数据治理。记住，日志不只是存储，它是你安全的金矿。

← 上一章 📖 返回目录 下一章 →