3. 日志采集：常用工具与协议对比与选型

日志采集是整个集中存储方案的第一步。这一步要是没走对，后面存储、分析全是白搭。我这些年见过的审计项目，一半的坑都埋在采集层。

说白了，采集层就是干三件事：搞到日志、传走日志、别丢日志。怎么搞？用什么协议？用什么工具？我们今天彻底聊透。

3.1 Syslog 协议：老牌但还在战斗

Syslog 是日志采集界的“活化石”。从 Unix 时代就在用，现在网络设备、Linux 系统、安全设备依然广泛支持。我个人觉得，只要你的设备支持 Syslog，就别折腾其他对接方式。

但要注意版本差异：

• RFC 3164（传统 Syslog）：UDP/514，传完就走，不确认。容易丢日志。
• RFC 5424（新式 Syslog）：支持 TCP/TLS，有结构化数据字段，可靠性更高。

所以我的建议是：审计日志采集，除非设备不支持，否则必须上 TCP 或 TLS 版本的 Syslog。丢日志等于没审计。

3.2 三大日志采集工具：你会选哪个？

现在市面上主流的日志采集工具有三个：Filebeat、Fluentd、Logstash。你想想看，一个 Go 写的，一个 Ruby 写的，一个 Java 写的。光语言差异就决定了它们的性格。

特性	Filebeat	Fluentd	Logstash
开发语言	Go	Ruby + C 插件	Java (JRuby)
资源占用	极低（10~50MB）	中等（50~200MB）	较高（200MB+，典型 512MB+）
原生协议	Filebeat 协议 / Syslog	HTTP / Forward / Syslog	HTTP / TCP / UDP / Syslog
过滤能力	基础（可配合 Elasticsearch Ingest）	中等（filter 插件丰富）	强大（grok、dissect、mutate）
输出目标	Elasticsearch / Logstash / Kafka	各种 Output 插件（ES、S3、MongoDB）	丰富 Output 插件（为主 ES、Kafka）
最适合场景	轻量边缘采集、简单转发	多云/混合架构、需要大量数据路由	复杂清洗转换、集中式处理

3.3 Filebeat：边缘利器，资源占得少

Filebeat 在我的项目里出现频率最高。Go 语言写的，安装包才十几兆，内存跑到 30MB 就能干活。你放在几百台服务器上，几乎感觉不到它的存在。

配置超级简单，举个例子：

# filebeat.yml 基础配置
filebeat.inputs:
- type: log
  paths:
    - /var/log/secure   # Linux 安全日志
    - /var/log/audit/*.log  # 审计日志

output.kafka:
  hosts: ["kafka1:9092", "kafka2:9092"]
  topic: "audit-logs"
  partition.round_robin:
    reachable_only: true

看到没？几行配置，就把审计日志送到 Kafka 了。它还自带背压机制，Kafka 写不动了，它会在本地排队，不会死循环重试。这一点比很多工具都靠谱。

Filebeat 的缺点也很明显：它不擅长复杂过滤。比如你想从一行日志里提取 IP、时间、操作类型，Filebeat 自己干不了，得配合 Logstash 或 ES Ingest Node 来做。

3.4 Fluentd：插件生态是它的王牌

Fluentd 是 CNCF 毕业项目，云原生圈子的宠儿。从 Kubernetes 到各种 SaaS 服务，都能看到它的身影。我用它做过一次跨公有云的多机房日志汇聚，效果还不错。

Fluentd 的核心优势是插件数量——官方和社区加起来有上千种。你想从某个冷门数据库拿日志？查一下，大概率有现成插件。

配置风格也是类 JSON 的，逻辑清晰：

# fluentd.conf 段配置
<source>
  @type tail
  path /var/log/audit/*.log
  format syslog
  tag audit.syslog
</source>

<filter audit.syslog>
  @type grep
  <regexp>
    key message
    pattern /FAILED|ERROR|DENIED/
  </regexp>
</filter>

<match audit.syslog>
  @type kafka2
  brokers kafka1:9092,kafka2:9092
  default_topic audit-logs
</match>

有人可能会问：Fluentd 和 Logstash 选谁？我的经验是——你团队如果有 Ruby 背景，或者混用多种输出目标（S3 + ES + 监控），Fluentd 是更好的选择。它吃内存比 Logstash 少一半。

3.5 Logstash：功能最强的老大哥

Logstash 是 ELK 三件套之一，Java 写的，功能最全，但也最重。我最早接触日志集中存储就是用它，那会儿它在 1.x 版本，稳定是稳定，就是启动慢、吃内存。

Logstash 的杀手锏是grok 正则解析。审计日志的格式五花八门，有 JSON、有 CSV、有自定义的。grok 模式库能让你用一行字符串就把结构拆得清清楚楚：

filter {
  grok {
    match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{SYSLOGHOST:host} %{DATA:program}: %{GREEDYDATA:message_content}" }
  }
  date {
    match => [ "timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
  }
  mutate {
    add_field => { "[@metadata][type]" => "audit" }
  }
}

但要注意，Logstash 不建议放在边缘服务器上。内存吃掉 500MB+，Java 堆栈一波动，直接影响业务。它更适合集中在后端的“日志处理集群”里。

3.6 选型决策矩阵

我整理了一个简单的决策逻辑，方便你对号入座：

1. 边缘采集（每台服务器都装） → 只用 Filebeat。
2. 中间路由（多层汇聚，多种输出） → Fluentd 或 Logstash。
3. 接口设备多（网络设备、安全硬件） → 强推 Syslog over TCP，丢给 Filebeat 或 Logstash 消费。
4. 清洗要求高（格式乱、需要实时解析） → Logstash 做集中清洗层。
5. 资源紧张（1000+ 节点，内存小于 4GB） → 坚决不用 Logstash，Filebeat + Fluentd 组合。

采集层选型就这么简单——别迷信工具，适合场景的才是好工具。下一节我们聊聊采集完之后的“数据管道与缓存”，毕竟只采集不消化，日志还是会淹死你。

嗯，这里要注意一点，不管选哪个工具，一定要考虑重传和背压机制。我习惯在生产环境先做一周的压力测试，确认工具在峰值流量下不丢日志、不撑爆内存，然后再上全量。这一点钱不能省。