📚 课程目录第4章日志收集架构

日志收集架构：Agent、API 采集、日志转发

做 SaaS 日志安全，第一关就是怎么把日志搞进来。你想想看，日志都收不到，后面分析、告警全白搭。我个人习惯把采集方式分成三大类：Agent 采集、API 采集、日志转发。它们各有各的脾气，选错了后面全是坑。

这一章咱们就把这三种架构掰开揉碎了讲清楚。我会结合自己踩过的坑，告诉你什么场景该用哪种，怎么搭才稳。

1. Agent 采集 —— 贴身盯防

Agent 说白了就是在目标服务器上装个小程序，让它把日志一条条往你中心平台送。常见的有 Filebeat、Fluent Bit、Vector 这些。

优点很明显：

能采集到一切本地文件 – 不管你日志写进文件还是 stdout，Agent 都能抓。
低延迟、实时推送。
可以做预处理（过滤、脱敏、结构化）。

缺点也得心里有数：

每台机器都要装，部署和维护工作量不小。
Agent 本身也吃资源，CPU 内存占用不可忽视。
如果 Agent 挂了，日志可能堆积甚至丢失。

个人经验：我在一家电商 SaaS 公司时，让运维所有服务器都装了 Filebeat。刚开始没留意日志轮转的速率，结果高并发时段 Filebeat 的吞吐跟不上，日志积压了好几万条。后来我在 Agent 配置里加了 backpressure 策略，一下稳了。

典型配置示例（Fluent Bit）：

[INPUT]
    Name          tail
    Path          /var/log/app/*.log
    Tag           app.*
    Multiline     On

[OUTPUT]
    Name          forward
    Match         app.*
    Host          collector.example.com
    Port          24224

嗯，这里要注意：Agent 采集模式对日志源环境有依赖，容器场景要配合 sidecar 模式。别图省事全用 DaemonSet 硬扛。

2. API 采集 —— 借接口拉取

很多 SaaS 服务不会让你装 Agent，比如 GitHub Actions、Slack、云厂商的审计日志。它们通常提供 RESTful API 或 SDK，你自己写程序去拉日志。

我常用的做法：写个定时任务（比如 5 分钟一次），调三方日志接口，把数据拉回来写到本地或直接发到 Kafka。

避坑指南：我曾经对接某云厂商的审计日志 API，没看文档里的限流参数，结果每分钟请求 300 次，直接被封 IP 两个小时。从那以后我所有 API 采集代码里都加了 指数退避重试 + 令牌桶限速。

维度	说明
方向	从服务端拉取（pull），不是推送（push）
延迟	取决于轮询间隔，通常分钟级
数据完整性	要看 API 是否支持按时间戳游标分页，否则容易漏
认证方式	OAuth2、、JWT 混合

建议：API 采集尽量用消息队列缓冲，防止目标平台抖动时数据丢失。我一般在 API 消费者后面接一个 Redis 或 Kafka topic，确保数据至少落地一次。

3. 日志转发 —— 中间人接力

很多时候你已经有了现成的日志管道（比如 syslog-ng、Rsyslog、Logstash、Fluentd），再搭一套 Agent 显得重复。这时候用“日志转发”架构——把现有系统的日志出口指向新的安全分析中心。

实施方式：

修改 syslog 配置文件，增加 remote destination。
在 Logstash 配置中增加 output 插件，同时发到 Elasticsearch 和你的安全平台。
用 Fluentd 的 copy 插件复制一份日志流。

核心优势：

零侵入，不需要改造应用。
可以利用已有的 HA 和缓冲机制。
适合异构环境混合转发。

我曾经踩过的坑：转发层如果使用 TCP 直连，上游宕机时日志会积压到 buffer 爆掉，最后丢数据。后来统一改成 Kafka 做中转层，虽然多了一个组件，但再没丢过日志。

三种架构对比

选哪个？我一般看三点：你能控制到什么程度、延迟容忍度、运维成本。下面这张表可以帮你快速决策。

采集方式	部署复杂度	延迟	数据完整性	适用场景
Agent 采集	中等（每台装 agent）	秒级	高（本地文件游标）	自建服务器、容器集群
API 采集	低（只要写一次采集程序）	分钟级	中（依赖 API 分页）	第三方 SaaS、云服务审计日志
日志转发	低（修改现有转发配置）	秒级~分钟级	依赖中转层可靠性	已有日志基础设施的场景

重要提示：生产环境不要只用一种采集方式。我推荐 Agent + 转发 混合使用：对重要业务日志用 Agent 独立采集，对基础设施日志用 syslog 转发。这样即使一条链路断了，另一条还能兜底。

架构总览图

下面我把三种采集形式画到一张图里，方便你理解整体数据流向。

画图的时候我把数据流分了三个层级：最上面是三种采集方式，中间用消息队列做缓冲和削峰，最终落地到存储分析平台。这样做的好处是任意一种采集出问题，其他两个还能正常干活。

我的一个小技巧：不管选哪种方式，先在采集端加一个“健康检测”指标（比如每分钟上报一次心跳）。我曾因为 API 采集挂了三天没发现，最后被客户投诉才知道——原来限流后采集程序直接退出了，连告警日志都没留下。后来我在每个采集任务里都加了心跳，配合 Prometheus Alertmanager，再没出过这种事故。

好了，关于日志收集的三种主要架构你心里应该有数了。接下来在实际落地时，记得根据你手上的 SaaS 环境灵活组合。别迷信某一种万能方案，适合的才是最好的。