日志采集架构设计：集中式 vs 分布式，Agent 部署方案

日志采集这步看似简单，不就是把日志拿过来吗？

但你想想看，当你的服务器从几十台涨到几千台，当你的业务从单体拆成微服务... 嗯，采集架构选错了，后面全盘都得重来。我在项目中踩过这个坑，所以今天专门聊聊这个话题。

为什么采集架构这么重要？

说白了，采集是合规治理的第一道关口。日志丢了你什么也查不了。

合规审计有个铁律：日志必须完整、不可篡改、可追溯。如果采集环节就出了问题，后面的存储和分析全是白费功夫。

我个人习惯，在设计采集架构之前，先回答三个问题：

• 日志从哪来？（来源多样性）
• 日志到哪去？（目标存储）
• 中间怎么传？（传输协议与缓冲）

这三个问题答案不同，架构选择也就不同。

集中式采集架构

集中式，听起来就是个“中心化”的思路。

所有日志收集到一台或者几台中心服务器，然后再统一转发到存储端。这种模式在传统运维里非常常见。

典型架构

• 日志源 → Agent → 中心收集器 → 存储
• 所有 Agent 把日志推送到同一个 Kafka 集群或 Logstash 实例

优缺点

优点	缺点
管理简单，运维成本低	单点故障风险，中心挂则全部断
配置统一，版本一致	中心节点容易成为性能瓶颈
审计链路清晰，便于合规审查	横向扩展受限于中心节点处理能力
数据汇总后去重、清洗方便	网络带宽集中在中心出口，容易打满

分布式采集架构

分布式，就是每个节点自己采集，自己处理，甚至自己先做一层汇聚，然后统一上报。

你想想看，在微服务和容器化环境下，日志源是动态的，Pod 起起灭灭，集中式根本搞不定。

典型架构

• 日志源 → 本地 Agent → 本地缓存/聚合 → 边缘节点 → 全局存储
• 每个 Kubernetes Node 部署 DaemonSet Agent，采集该节点所有 Pod 日志
• 边缘节点做第一层聚合和过滤，只上传合规相关日志

优缺点

优点	缺点
高可用：一个节点故障不影响其他节点	运维复杂度高，每个节点都要监控
横向扩展：加节点就行，几乎没有瓶颈	配置分散，版本管理需要自动化工具
带宽友好：每个节点只用自己的出口	审计追踪难度增加，日志分散在各处
适合动态环境：自动发现新 Pod	多了一层边缘计算，延迟略高

两种架构的选择策略

做选择其实没那么复杂。我归纳了一个简单的判断表。

场景	推荐架构	原因
服务器数量 < 50，日志量稳定	集中式	运维简单，成本低，管理方便
服务器数量 > 200，日志量波动大	分布式	避免单点瓶颈，扩展性好
容器化、微服务环境	分布式	动态发现，Pod 生命周期内采集完整
合规审计要求极高（金融、医疗）	集中式为主 + 分布式补充	中心化审计链路清晰，边缘做第一层过滤减少中心压力
跨地域、多机房	分布式 + 区域汇聚	每个区域先汇聚，区域间通过专线同步

说白了，没有银弹。实际项目里我见过大部分选择是混合模式：核心系统走集中式确保审计完整性，边缘或非核心系统走分布式分担压力。

Agent 部署方案归纳

采集架构定下来之后，Agent 怎么部署就是下一个大问题。

我记得有一次合规审计，监管要求提供半年前某天的日志，结果发现 Agent 配置改了但没更新到所有机器，一半日志格式是旧的。那叫一个惨。所以 Agent 部署必须规范化。

三种主流部署方式

1. 直接部署在业务服务器
   • Agent 作为进程运行在每台业务机器上
   • 优点：本地采集延迟最低，资源可控
   • 缺点：与业务进程争抢资源，需要业务团队配合
   • 适用场景：传统物理机或 VM，日志量中等
2. Sidecar 模式（容器环境）
   • 每个 Pod 内启动一个 Sidecar 容器负责日志采集
   • 优点：日志采集与应用容器隔离，不影响主进程
   • 缺点：每个 Pod 多一个容器，资源开销翻倍
   • 适用场景：Kubernetes 环境，需要按 Pod 隔离
3. DaemonSet 模式（容器环境）
   • 在每个 K8s Node 上部署一个 Agent Pod，采集该节点所有日志
   • 优点：资源开销小，一个 Agent 管整个节点
   • 缺点：无法精细控制每个 Pod 的采集策略
   • 适用场景：集群规模大，日志类型相对统一

Agent 配置管理最佳实践

• 配置中心：所有 Agent 配置统一托管，不要手动 SSH 上去改。我推荐用 etcd 或 Consul。
• 灰度发布：新配置先推给 5% 的 Agent，观察 10 分钟再全量。我在项目中吃过亏，一次配置错误导致所有 Agent 挂了，日志全断。
• 健康检查：每个 Agent 定期上报心跳，如果某个 Agent 超过 15 秒没消息就告警。合规审计要求“断连必须 5 分钟内发现并恢复”，我实测 15 秒比较合理，太短容易误报。
• 版本管理：Agent 版本和配置版本都要记录，方便回滚。审计时监管可能会问“某天你的 Agent 是什么版本？”如果不能回答，那就是严重不合规。

核心知识结构

这个图展示了我对日志采集架构的理解路径。从上到下分两层：第一层是选集中还是分布式，第二层是在架构基础上选 Agent 部署方式。

每次做新项目，我就拿这张图过一遍，基本上不会出大问题。

总结几个关键点

• 先定架构再选 Agent：不要先选 Agent 再凑架构，顺序反了后面会很被动。
• 缓冲是命：不管选哪种架构，Agent 本地的磁盘缓冲一定要开。网络抖一抖，日志不能丢。
• 元数据必须打全：来源主机、Agent 版本、采集时间，这三个字段是合规审计的底线。缺一个，审计时就准备补报告吧。
• 做好灰度能力：Agent 升级或配置变更，永远先小范围验证。我曾经一次误操作导致全量 Agent 发送错误格式，存储端解析全崩，恢复花了一整天。