日志采集原理：Agent模式 vs 无Agent模式、推送 vs 拉取
讲日志采集，绕不开两个核心问题：装不装Agent，以及谁来主动发起数据流。
很多人觉得这不过是技术实现差异，选一个就行。但我在实际项目中踩过不少坑——选错了模式，后期运维成本能翻好几倍。今天咱们就把这两个维度拆开说清楚。
一、Agent模式 vs 无Agent模式
先看第一个维度，是否在被采集的机器上安装专门的软件。
1. Agent模式
Agent模式，说白了就是在每一台需要采集日志的服务器上，装一个小程序。这个程序负责读取日志文件、监听端口或获取系统日志，然后发送到中央处理平台。
典型代表：
- Filebeat（Elastic Stack 轻量采集器）
- Fluentd / Fluent Bit
- Logstash
- Vector
优势：
- 可控性强：采集频率、过滤规则、传输压缩全由你定
- 资源隔离：采集进程独立，不影响业务应用
- 断点续传：Agent挂了重启后，能从断点继续，不会丢数据
- 支持复杂处理：可以在采集端做字段提取、格式转换
劣势：
- 部署工作量大：300台机器就要装300个Agent
- 版本管理麻烦：升级Agent需要完善的灰度发布机制
- 占用系统资源：虽小但积少成多，我见过一个团队因为Agent配置不当，把业务服务器的CPU打满了
🔑 我的建议： 如果你的服务器超过50台，或者日志量在100GB/天以上，我强烈推荐用Agent模式。长痛不如短痛——部署阶段多花三天，后期运维能省三个月。
2. 无Agent模式
无Agent模式，乍一听很美好——不用装任何东西，通过网络协议直接拉取日志。
常见方式：
- Syslog 协议（UDP 514 或 TCP 514）
- SNMP Trap
- SSH 远程读取日志文件
- API 轮询（如云平台的日志接口）
- Kubernetes 标准输出（stdout/stderr）
优势：
- 零侵入：不需要在被采集端装任何软件
- 部署极快：配置完采集端，任务完成一半
- 统一管理：所有采集配置在中心节点，不用登录每台机器
劣势：
- 协议限制：Syslog 只支持特定格式，且UDP模式下可能丢包
- 可扩展性差：SSH拉取上万台机器时，连接数会成问题
- 断点能力弱：SSH拉日志过程中断，大概率要重头拉
- 安全风险：SSH密钥、Syslog明文传输，都需要额外加密
⚡ 我曾经踩过的坑： 有一个项目，客户为了省事，对所有服务器用SSH拉取日志。前期20台机器跑得好好的，后来扩展到500台，SSH连接数直接把管理节点打崩了。最后老老实实切回Agent模式。如果你告诉我无Agent模式比Agent模式简单——嗯，那是你还没见过服务器上规模的样子。
二、Push vs Pull
第二个维度，是谁主动发起数据传输。这直接影响系统架构和压力分布。
1. Push模式（推送）
日志产生端主动把数据推送到中央平台。典型的Push模式就是Agent配置好目标地址，不断往里发数据。
特点：
- 采集端主动：Agent控制节奏，中央平台被动接收
- 低延迟：日志产生后几乎实时到达
- 去中心化：采集端之间无依赖，一个挂了不影响其他
- 适合海量数据：每个Agent各自负责，避免集中轮询瓶颈
常见实现：
- Filebeat → Elasticsearch / Logstash
- Fluent Bit → Kafka / S3
- Vector → ClickHouse
2. Pull模式（拉取）
中央平台主动去日志源获取数据。无Agent模式大多采用这种方式。
特点：
- 中心控制：采集节奏由中心节点决定
- 延迟较高：轮询周期内数据在源端等待
- 中心压力大：节点数越多，中央负载线性增长
- 调度灵活：可以根据中央资源情况动态调整采集频率
常见实现：
- Logstash 通过 JDBC 拉取数据库日志
- Prometheus 拉取应用指标（虽然不是日志，但模式相同）
- 自定义脚本通过 SSH 拉取远程日志文件
| 对比维度 | Push 模式 | Pull 模式 |
|---|---|---|
| 延迟 | 秒级（实时） | 分钟级（依赖轮询周期） |
| 中心负载 | 低（被动接收） | 高（主动扫描） |
| 扩展性 | 线性扩展 | 中心成为瓶颈 |
| 断点续传 | 容易实现 | 复杂 |
| 安全风险 | 较低（仅单向端口） | 较高（需要认证凭证） |
| 典型场景 | 大规模生产环境 | 临时接入、边缘设备 |
💡 一个小技巧： 在实际选型时，Push 和 Pull 不是互斥的。我做过一个混合方案——核心业务用 Filebeat Push 到 Kafka，而一些老旧设备只支持 SNMP，就用 Pull 方式定期抓取。这样既保证了核心链路的实时性和可靠性，又兼容了存量设备。
三、组合决策：选型矩阵
两个维度交叉后，会得到四种组合。我把它们整理成一张表，方便你对照选择。
| 组合 | 模式 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|---|
| ① Agent + Push | 标准方式 | 实时、可控、可扩展 | 部署工作量大 | 生产环境、大规模集群 |
| ② Agent + Pull | 反模式 | 中心控制采集节奏 | 资源浪费（Agent闲置） | 极少使用，除非有特殊监管需求 |
| ③ 无Agent + Push | Syslog方式 | 零部署、快速接入 | 格式受限、可能丢包 | 网络设备、防火墙日志 |
| ④ 无Agent + Pull | SSH/API方式 | 完全无侵入 | 可扩展性差、中心压力大 | 临时采集、容器标准输出 |
说起来，你可能会问我：到底选哪个？我的经验是——默认选 ① Agent + Push。这是经过千锤百炼的标准模式。
只有在以下几种情况，才考虑其他组合：
- 网络设备只支持 Syslog → 选 ③
- 临时接入几台服务器做诊断 → 选 ④
- 想给自己找麻烦 → 选 ②（开个玩笑，别选）
四、知识体系图解
下面这张图，把今天聊的两个维度和四种组合串在一起。用SVG画的，你一看就明白。
五、总结：选型记住三句话
说到底，日志采集模式没有银弹。但记住这三句话，能帮你少走弯路：
- 面向生产环境，优先选 Agent + Push。 这是主流方案，社区支持好、运维工具多。
- 网络设备、嵌入式系统，用无Agent模式。 不是你不想装，是装不了。
- 混合架构是常态。 核心链路Push，外围设备Pull，两手都要抓。