采集架构选型：Agent模式 vs Agentless模式，推模式 vs 拉模式
日志采集架构怎么选？说实话，这是每个团队起步时都会纠结的问题。我见过不少项目，一开始拍脑袋选了某种模式，结果半年后改得面目全非。今天咱们就把这四种模式掰开揉碎，看看它们到底适合什么场景。
核心观点：没有银弹。选型的关键在于你的环境规模、运维能力和对资源消耗的容忍度。
Agent模式 vs Agentless模式
这两种模式的区别，说白了就是：要不要在目标机器上装一个常驻进程。
Agent模式
在每台需要采集日志的服务器上，部署一个独立的采集程序。这个程序负责读取日志文件、解析、过滤，然后发送到中央存储。
优点：
- 资源隔离好：采集进程独立运行，不会影响业务进程。我记得有一次线上事故，业务进程把CPU吃满了，但采集Agent因为做了资源限制，日志照常上报，排查问题全靠它。
- 灵活性高：可以针对不同日志格式做定制化处理。比如Nginx日志和Java应用日志，解析规则完全不同，Agent可以各自配置。
- 网络压力分散：每个Agent独立发送数据，不会形成单点瓶颈。
缺点：
- 运维成本高：成百上千台机器，每台都要部署、升级、监控Agent。我曾经维护过3000+节点的集群，光Agent版本升级就折腾了两周。
- 资源占用：每个Agent都会消耗CPU和内存。虽然单个占用不大，但积少成多。我见过一个极端案例，Agent内存泄漏，把业务服务器的内存吃光了。
- 安全问题：Agent需要读取日志文件，如果权限控制不当，可能成为攻击入口。
Agentless模式
不安装任何客户端，通过远程协议（如SSH、WinRM、API）从目标机器拉取日志。
优点：
- 部署简单：不需要在每台机器上装东西，对业务零侵入。特别适合容器化环境，你想想看，容器重启后Agent就没了，Agentless模式就没这个烦恼。
- 集中管理：所有采集任务都在中央服务器上配置，变更一次生效。
- 资源节省：目标机器上不跑额外进程，资源全部留给业务。
缺点：
- 性能瓶颈：中央采集服务器要同时连接大量目标机器，很容易成为瓶颈。我遇到过一台采集服务器同时拉取500台机器的日志，结果网络连接数爆了。
- 实时性差：轮询方式采集，做不到秒级延迟。一般分钟级是常态。
- 安全风险：中央服务器需要拥有目标机器的访问权限，一旦被攻破，所有机器都暴露了。
| 对比维度 | Agent模式 | Agentless模式 |
|---|---|---|
| 部署复杂度 | 高，每台机器都要装 | 低，只需配置中央服务器 |
| 资源消耗 | 分散在每台机器 | 集中在采集服务器 |
| 实时性 | 秒级 | 分钟级 |
| 运维成本 | 高，版本管理麻烦 | 低，集中管理 |
| 安全性 | 需控制Agent权限 | 需保护中央服务器凭证 |
| 适用场景 | 大规模、高实时性要求 | 小规模、容器化、临时采集 |
避坑指南：我曾经在容器化环境中强行使用Agent模式，结果每次容器重启都要重新部署Agent，运维量翻了三倍。后来换成Agentless模式，配合Kubernetes API动态发现容器，问题才解决。
推模式 vs 拉模式
这两个模式解决的是数据流向问题：是采集端主动发，还是服务端主动取。
推模式（Push）
采集端主动将日志数据发送到中央存储。这是目前最主流的模式。
优点：
- 实时性好：日志产生后立即发送，延迟低。我习惯用推模式做告警日志采集，因为延迟超过10秒，告警就失去意义了。
- 架构简单：采集端只管发，服务端只管收，逻辑清晰。
- 扩展性好：增加采集节点不会影响现有架构，只需要在服务端扩容接收能力。
缺点：
- 数据可靠性依赖网络：如果网络抖动，数据可能丢失。我遇到过采集端发送成功但服务端没收到的情况，排查了半天才发现是中间的网络代理丢包了。
- 服务端压力大：所有采集端同时推送，服务端需要扛住峰值流量。
- 难以回溯：如果服务端宕机，这段时间的数据就丢了，除非采集端有本地缓存。
拉模式（Pull）
中央服务端主动从采集端拉取日志数据。
优点：
- 控制权在服务端：服务端可以控制拉取频率、并发数，避免过载。你想想看，如果业务高峰期日志量暴增，推模式可能把服务端打垮，但拉模式可以主动降速。
- 数据可靠性高：拉取失败可以重试，服务端有完整的重试机制。
- 便于审计：所有拉取行为都有记录，谁在什么时候拉了哪些数据，一清二楚。
缺点：
- 实时性差：轮询间隔决定了延迟，做不到秒级。
- 服务端复杂度高：需要维护连接池、任务调度、失败重试等逻辑。
- 采集端需要暴露接口：每个采集端都要开放端口，增加了安全风险。
| 对比维度 | 推模式 | 拉模式 |
|---|---|---|
| 实时性 | 秒级 | 分钟级 |
| 服务端复杂度 | 低，只管接收 | 高，需管理拉取任务 |
| 数据可靠性 | 依赖采集端重试 | 服务端可控重试 |
| 流量控制 | 被动，无法控制 | 主动，可限流 |
| 适用场景 | 实时监控、告警 | 批量采集、数据同步 |
个人经验：我建议在实时性要求高的场景用推模式，比如业务监控、安全审计。在数据量巨大且需要精细控制的场景用拉模式，比如离线数仓的数据同步。实际项目中，我经常把两者结合：推模式做实时链路，拉模式做数据补录。
四种模式的组合选择
实际项目中，很少只用一种模式。常见的组合方式有四种：
- Agent + 推模式：最主流方案。Filebeat、Logstash、Fluentd都是这种模式。适合大规模生产环境。
- Agent + 拉模式：较少见。采集端暴露HTTP接口，服务端定期拉取。适合跨网络隔离的环境。
- Agentless + 推模式：容器化环境常用。业务容器通过SDK直接推送日志到中央存储。
- Agentless + 拉模式：运维审计场景。通过SSH远程拉取系统日志。
我的建议：如果你刚开始搭建日志系统，从「Agent + 推模式」入手最稳妥。等规模大了，再考虑引入Agentless模式做补充。别一开始就搞混合架构，容易把自己绕进去。
架构选型决策流程
下面这张图是我自己总结的选型决策流程，帮你快速定位适合的模式：
避坑指南：我曾经在一个项目中，团队为了「技术先进性」选择了全Agentless+拉模式。结果业务高峰期，中央采集服务器CPU打满，日志延迟超过30分钟。最后不得不紧急切换到Agent+推模式，才把延迟降下来。记住：先进性不等于适用性。
总结
选型没有标准答案，但有决策依据。我个人的经验是：
- 大规模生产环境：Agent + 推模式，稳定可靠
- 容器化环境：Agentless + 推模式，灵活轻量
- 跨网络隔离：Agent + 拉模式，可控性强
- 临时采集任务：Agentless + 拉模式，快速部署
嗯，这里要注意一点：无论选哪种模式，都要考虑数据丢失的兜底方案。我习惯在采集端加本地缓存，在网络恢复后自动补发。这个细节，后面章节会详细讲。