第 2 章 日志采集技术：从源头到管道

大家好，咱们接着聊。日志采集这事，说白了就是「把散落各处的记录收上来」。你想想看，没有采集，后面所有检测全是空谈。我在好几个安全项目里都遇到过：告警平台搭得花里胡哨，结果日志没采全，攻击已经走了好几轮，平台还在那岁月静好。所以这一章，咱们把日志来源、采集方式、架构设计掰开揉碎聊透。

2.1 日志来源：那些散落的碎片

我习惯把日志来源分成三大类：系统层、应用层、网络层。别小看分类，很多团队一开始只采应用日志，结果攻击者改个系统配置，完全看不见。

类别	典型来源	关键内容	采集难度
系统层	Linux /var/log/secure, Windows Event Log	登录、提权、进程创建、文件操作	低
应用层	Nginx access/error, Tomcat catalina.out, 自研业务日志	API 调用、SQL 注入、越权、业务异常	中
网络层	防火墙、IDS/IPS、DNS、NetFlow	连接建立、协议异常、DNS 隧道、流量特征	高

2.2 采集方式：因地制宜，别瞎选

选采集方式，你得先搞清楚两个问题：日志多不多？要不要实时？下面我把主流方式挨个说。

Agent 模式

在服务器上装个小程序，比如 Logstash Forwarder、Fluent Bit、Aliyun Logtail。Agent 自己读文件、发数据，不用改系统配置。我在一个日活千万的电商平台用过 Fluent Bit，单核 CPU 的采集开销不到 5%，完全能接受。

Syslog 协议

几乎所有网络设备和 Linux 服务器都支持。你配置一下 rsyslog 或 syslog-ng，把日志发给中央服务器。注意一点：标准的 UDP 514 端口不可靠，丢日志是常态。我建议在传输层改用 TCP 或 RELP 协议。

# rsyslog 配置示例：把安全日志集中发到 192.168.1.100
# 使用 TCP 保证传输可靠
*.* @@192.168.1.100:514

Filebeat + Logstash / Kafka

这是目前 Elastic Stack 生态最流行的组合。Filebeat 负责读文件、做简单的字段提取，然后推给 Logstash 做复杂解析，或者直接塞进 Kafka 作为缓冲。好处是轻量、稳定，还能做背压管理——Logstash 挂了，Filebeat 会自己等，不丢数据。

# filebeat.yml 关键配置
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/*.log
  fields:
    source_type: linux_syslog
output.kafka:
  hosts: ["kafka1:9092", "kafka2:9092"]
  topic: "raw-logs"
  partition.round_robin:
    reachable_only: true

2.3 采集架构：别让管道变成瓶颈

单机采集很简单，但生产环境往往几百上千台服务器。我个人习惯把架构分成三层：采集层、缓冲层、处理层。下面这张图你一定得记住。

三层架构的核心逻辑：采集层只负责「读」和「发」，缓冲层吸收流量毛刺，处理层专注解析和检测。我见过有人把 Logstash 直接挂到几十台服务器上，结果 Logstash 一挂，全丢—幸亏加了 Kafka，数据才没丢。

2.4 避坑指南：我踩过的那些坑

• 日志重复：曾经有一次，Filebeat 和 syslog 同时采集同一份日志，导致 ES 里重复记录翻了 3 倍。解决方案是采前做去重签名——对日志内容 + 时间戳取 MD5，发现重复就丢弃。
• 磁盘写满：采集代理如果没做日志轮转（log rotation），一天就能写满 500GB。我习惯在 Agent 配置里加上 max_size: 100MB 和 keep_files: 7。
• 压缩传输：生产环境日志流量高峰能到 1Gbps，建议采集层启用 Gzip 压缩后再发，能省 80% 带宽。