📚 课程目录第3章审计数据采集

审计数据采集：日志收集工具与方法

日志收集，是整个异常检测链条的第一道关口。

你想想看，如果源头数据丢了、晚了、坏了，后面的模型再漂亮也没用。我见过太多项目，把精力全砸在算法调参上，结果发现日志采集那边就漏了一半——那基本上是白干。所以咱们先把基础打牢。

这一章，咱们重点聊三个工具：syslog、Flume 和 Filebeat。它们各自适合什么场景？配置上有什么坑？我会结合真实项目经验跟你掰扯清楚。

为什么先聊日志收集？

审计日志从哪来？无外乎系统日志（syslog）、Web服务器访问日志、数据库审计日志、容器标准输出……它们分散在各台机器上。我们需要一个可靠、低延迟的管道，把日志弄到统一存储里。

选工具没有银弹。我个人习惯这样判断：

已有 Elastic 全家桶？ 直接上 Filebeat，和 ES 是无缝衔接。
需要做复杂过滤、聚合、多路分发？ Flume 的 Agent-Channel-Sink 架构更灵活。
只是集中收系统日志，不想装额外的 agent？ syslog 是原生方案，但小心丢包。

syslog：最老牌，但也最“糙”

syslog 协议（RFC 5424）是 Unix/Linux 系统的标准日志协议。它的优点就是简单：设备往 UDP 514 端口丢数据就行了。缺点也很明显——

⚠ 我曾经踩过的坑： 用 UDP 收 syslog，流量一高就会丢日志，而且你完全不知道丢了。后来我强制切换成 TCP + RELP（可靠事件日志协议），才算解决这个问题。

建议：生产环境一定要用 TCP 模式，或者搭配 rsyslog 的 RELP 模块。

syslog 消息格式长这样：

<PRI>TIMESTAMP HOSTNAME APP[PID]: MESSAGE
例：
<13>2025-03-15T10:30:00Z webserver01 sshd[12345]: Failed password for root from 192.168.1.100 port 22

实际项目里，我一般用 rsyslog 作为 syslog 服务端，它支持多规则、模板、甚至直接输出到 Kafka。

Flume：大吞吐、可编排的 ETL 管道

Flume 是 Apache 旗下的，最初为 Hadoop 生态设计。它的核心概念就三个：Source、Channel、Sink。

你可以把它想象成一个积木：Source 负责读数据（比如 TailDir Source 实时监控文件），Channel 作为缓冲（内存或文件），Sink 负责写出去（HDFS、Kafka 等）。

💡 我的经验： Flume 最擅长处理“既有结构又不规则”的日志。比如我们要采集混合了 Apache 和 Nginx 的日志，在 Flume 里可以用 Interceptor 做正则解析、加字段、过滤。一套配置搞定，不用写额外代码。

一个简化的 Flume 配置示例（监控目录并写入 HDFS）：

agent.sources = r1
agent.sinks = k1
agent.channels = c1

agent.sources.r1.type = spooldir
agent.sources.r1.spoolDir = /var/log/audit
agent.sources.r1.interceptors = i1
agent.sources.r1.interceptors.i1.type = regex_filter
agent.sources.r1.interceptors.i1.regex = ^\d{4}-\d{2}-\d{2}

agent.sinks.k1.type = hdfs
agent.sinks.k1.hdfs.path = /logstash/audit/%Y%m%d
agent.sinks.k1.hdfs.fileType = DataStream

agent.channels.c1.type = file
agent.channels.c1.checkpointDir = /flume/checkpoint
agent.channels.c1.dataDirs = /flume/data

agent.sources.r1.channels = c1
agent.sinks.k1.channel = c1

注意这里的 Channel 我特意用了 file 类型。为什么？内存 Channel 虽快，但 agent 崩了会丢数据。生产环境我坚持用 file channel，代价就是多一点磁盘 IO，但换来了可靠性。

Filebeat：轻量、傻瓜式、Elastic 标配

Filebeat 属于 Elastic Stack（ELK）的一部分。它天生就是用来采集日志并发送到 Elasticsearch 或 Logstash 的。

和 Flume 比，Filebeat 更“轻”——一个二进制文件，零依赖，内存占用常年在 30MB 以下。配置也极其简洁：

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/auth.log
    - /var/log/syslog
  multiline.pattern: '^\s'
  multiline.negate: false
  multiline.match: after

output.elasticsearch:
  hosts: ["localhost:9200"]

我个人特别喜欢它的 multiline 处理——比如 Java 的堆栈异常，跨多行，Filebeat 能自动合并成一条事件。Flume 处理这个就比较麻烦。

  🔔 注意： Filebeat 默认使用背压机制。当 ES 写入变慢时，Filebeat 会自动减慢读取速度，避免内存暴涨。这点比早期的 Logstash 做得好。

当然，Filebeat 也有短板：如果你需要对日志做复杂的路由、聚合、与外部系统对接，它的处理器（Processor）能力有限。这时候一般前面 Filebeat 采集，后面接 Logstash 或 Kafka 做二次处理。

三款工具横向对比

维度	syslog (rsyslog)	Flume	Filebeat
部署复杂度	低（系统自带）	中（依赖 Java）	极低（单二进制）
吞吐量	中（UDP 可能丢包）	高（可分布式）	中高（Go 编写，I/O 高效）
可靠性	低（UDP 无确认）	高（支持事务）	高（ack + 背压）
数据处理能力	弱（仅转发）	强（Interceptor + 自定义）	中（简单过滤、字段处理）
典型输出	文件、TCP、Kafka	HDFS、Kafka、HBASE	ES、Logstash、Kafka
适用场景	系统日志集中、VPN、防火墙	大数据管道、ETL清洗	ELK 审计日志、容器日志

我的选择原则

说实话，现在新项目我首选 Filebeat。因为大部分审计异常检测最终要落到 Elasticsearch 或者 Kafka 上，Filebeat 天然适配。但如果你手头是 Hadoop 大数据平台，Flume 依然是不可替代的选择。至于 syslog，嗯，它就像瑞士军刀——简单可靠，但别指望它做复杂处理。

⚠ 避坑提醒： 如果你的审计日志包含敏感信息（如用户密码尝试），记得在采集端做脱敏或过滤。我曾经见过一个团队把全量登录日志直接送进 ES，结果被合规审计打回重做。Filebeat 可以用 processor 加 drop_fields 或 mask 处理器，Flume 则用 Interceptor 正则替换。

最后说一句：不管你用哪个工具，一定要加监控。我习惯给每个采集 agent 暴露一个 metrics 端口（Filebeat 默认有，Flume 要配 JMX），实时看：每秒采集条数、延迟、错误率。这样才能在数据管道出问题前提前干预。