📚 课程目录第3章审计日志采集架构

3. 审计日志采集架构：从源头到管道的实战经验

日志采集这件事，听起来好像就是把机器上的日志文件读出来，发到后端去。嗯，其实没这么简单。我在不少项目里见过，采集架构搭不好，后面告警全乱套。不是丢了日志，就是采集器把业务系统拖慢，运维同事直接来找我“喝茶”。

今天我就把日志采集这块掰开揉碎，从源头识别到采集方式选择，再说说性能怎么优化。你把这些吃透了，至少能避开我当年踩过的那些坑。

3.1 日志源识别：你得知道你的数据从哪来

先问一个问题：你的审计日志到底从哪来？别笑，真有人答不上来。我建议你按下面三个维度去梳理日志源。

安全设备：防火墙、IDS/IPS、VPN、WAF。这类设备通常支持 Syslog 或 SNMP Trap，日志格式比较固定。
服务器与中间件：Linux/Windows 的操作系统日志、Nginx/Apache 的访问日志、Tomcat/WebLogic 的应用日志。文本文件居多。
业务应用：自研系统的业务操作日志、数据库的审计日志、云平台的 API 调用日志。格式最乱，也是最容易遗漏的地方。

一个小建议：做日志源梳理时，别只盯着 IT 部门问。去找业务部门聊一聊，他们手里经常有一些“没人知道”的日志文件，里面藏着关键审计线索。

日志源类型	常见协议/格式	采集难度	典型场景
网络设备	Syslog (RFC 3164/5424)	低	防火墙 deny 日志、VPN 认证日志
服务器 OS	rsyslog、EventLog、文本文件	中	Linux secure 日志、Windows 安全日志
业务应用	JSON、自定义格式、数据库表	高	电商订单操作日志、银行核心交易日志

我在某金融客户那里踩过一个坑。当时只采集了网络设备和服务器的日志，业务应用的日志完全没管。结果有一次安全事件需要回溯，发现关键操作日志全在应用层，而采集架构里根本没这一项。嗯，后来只能硬着头皮人工补采，那叫一个痛苦。

避坑指南：我曾经接手过一个项目，日志源识别只做了两天的“拍脑袋”梳理。上线后才发现，有 30% 的日志源根本没列进去。结果呢？每天都要手动补采集规则，运维团队直接崩溃。所以我的建议是，拿出一周时间，逐个系统去确认，宁可多列也别漏。

3.2 采集方式：Agent、Syslog、API，怎么选？

确定了日志源，下一步就是选采集方式。说白了，就三种主流玩法：Agent、Syslog、API。我一个个说。

3.2.1 Agent 采集

Agent 是最灵活的方式。你在目标机器上装一个采集程序，它负责读文件、解析、压缩、发送。

优点：能处理复杂格式，支持断点续传，采集后还能做本地过滤。
缺点：有侵入性，需要运维团队配合部署，版本管理也比较麻烦。

# 一个简化版的 Agent 采集配置（Filebeat 风格）
filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /var/log/secure
      - /var/log/audit/audit.log

output.redis:
  hosts: ["192.168.1.100:6379"]
  key: "audit_log"

我个人习惯是，对于服务器和中间件的日志，优先用 Agent。因为它最可控，你能精确控制采集什么、怎么采，而且出了问题自己能快速定位。我在一个证券客户那里部署了 500 个 Agent，跑了一年多，基本没出过问题。

3.2.2 Syslog 接收

Syslog 是最老的玩法之一，也是网络设备的标准配置。你搭一个 Syslog 服务器，设备主动把日志发过来。

优点：零侵入性，设备只需要配置一个目标地址。
缺点：可靠性一般（默认用 UDP），存在丢包风险；日志格式不统一，解析工作量较大。

遇到 Syslog 采集设计，我建议生产环境还是走加密通道，比如用 RELP（Reliable Event Logging Protocol）或者加 TLS。我在一个跨国企业遇到过，他们用普通 UDP 采集，丢包率高达 5%，告警分析直接废了。

3.2.3 API 拉取

这个适合云平台和 SaaS 服务。你通过 REST API 或者 SDK，定时去拉取审计日志。

优点：完全无侵入，不依赖目标系统修改配置。
缺点：受 API 限速和调用频率限制，数据实时性较差。

我曾经见过一个项目，用 Python 脚本轮询调用 API 采集日志。结果呢？拉取周期是 5 分钟，每次限速 1000 条。日增量 10 万条日志时，就会积压。所以用 API 采集，一定要评估好日志量和 API 的吞吐能力。

采集方式	侵入性	可靠性	适用场景
Agent	高（需部署）	高	服务器、中间件、应用
Syslog	低	中（UDP 有丢包风险）	网络设备、安全设备
API	无	中（受限于限速）	云平台、SaaS 服务

3.3 采集性能优化：日志量大了怎么办？

日志量一旦上去，采集环节就成了第一个瓶颈。我见过不少系统，一天采集几十 GB 日志，采集器 CPU 冲到 100%，业务系统都跟着受影响。

    核心思路：采样的目标是“不丢关键日志，但可以放弃低价值日志”。

3.3.1 批量采集与压缩

别一条一条地发送。攒一批，比如每 1000 条或者每 5 秒钟，打包压缩后再发出去。这样能大幅降低网络开销和 IO 次数。我在一个电商大促项目中，用了 Gzip 压缩，日志传输量直接降了 70%。

3.3.2 采样与降噪

有些日志重复率极高，比如网络设备的 keep-alive 日志，或者业务系统的健康检查日志。可以直接在采集端做过滤，或者配置采样比例。比如，只采集 10% 的 debug 日志，但全量采集 error 和 warning 日志。

3.3.3 日志预处理

如果后端是全文搜索引擎，直接扔原始日志进去，存储和索引压力都很大。我建议在采集阶段就做一次简单的清洗：去掉无用字段、规整时间格式、提取关键标签。

注意：我曾经犯过一个错误，在采集端做了过于复杂的预处理，结果采集器本身就成了瓶颈。所以，预处理一定要适度，只做必要操作。复杂的解析逻辑，留给后面的流处理引擎去做。

下面是日志采集架构的整体流程，我画了一张图，方便你理解。

说到底，审计日志采集架构的核心就三条：识别全日志源、选对采集方式、做好性能优化。你按照这个框架去设计，基本不会出大问题。如果还有其他场景需要讨论，随时可以找我聊聊，我这里有太多的实战案例可以分享。