1.2 选型对比：现成采集器与自研

日志管道第一步的永恒争论：用现成采集器（Filebeat、Fluentd、Vector）还是自己写？支持现成的人说「别重复造轮子」，支持自研的人说「我们的需求特殊」。本篇把这笔账算清楚，给一个能拍板的框架。

现成采集器的优势与边界

现成采集器开箱即用、生态成熟，配置文件就能跑出第一版。但它们有自己的舒适区：擅长「文件或网络流 → 统一后端」的标准化搬运，一旦要做深度定制（按业务规则改解析、多级降级、嵌入公司内部鉴权与脱敏），就要写插件，复杂度并不比自己写少。

对「吞吐有要求、定制规则多、跑在业务机旁边」的场景，自研的资源优势会被放大：采集器省下的内存，就是业务能多扛的并发。

算清「轮子税」

造轮子要交税，先把税目列清楚：解析层（JSON/正则/自由文本）、背压与限速（保护业务机）、(Output) 多目的端（COS、CLS、Kafka）、监控自身指标（吞吐、丢弃、积压）、热更新（不重启改配置）。这五项在现成采集器里都有对应开关，自研则要逐个实现。如果五项全部都要，自研成本其实不低；如果只取其中两三项，自研反而清爽。

混合路线：现成采集 + 自研汇聚

混合路线的代价是多一跳网络与一次序列化，但换来了「边缘极稳、中心极活」的架构。边缘出问题影响面大，所以用最成熟的；中心出问题影响面小但改动频繁，所以用最可控的。这个分工与 Go 微服务实战 里「边车与服务治理」的分层思路一致。

现成采集器的三个典型天花板

给「再想想」的人三个具体的天花板，都是实战里反复出现的。第一是解析嵌套与变体：现成解析器对标准 JSON 得心应手，但带时间戳前缀、嵌套自由文本的混合行，往往要堆正则，维护到后面正则集比代码还难懂。第二是降级策略插不进去：高峰期想按业务线分级采样，现成工具的限速是全局的，做不到「核心日志保量、审计日志降级」。第三是资源尖峰不可控：采集器内存随日志行长度波动，遇到超长行能瞬间涨到 GB 级，威胁同机业务。三条都落在「精细化控制」上，也正是自研最能发力的地方。

反过来，如果这三条都不痛，那就是现成采集器的舒适区，自研纯粹是给自己加戏。

决策树：三问定选型

如果团队还在纠结，用三问快速定。第一问：定制规则有多少？ 五条以内选现成，十条以上且常变化选自研。第二问：采集器跑在哪？ 跑专用机器可以现成，跑业务机旁必须考虑资源，Rust 自研优势最大。第三问：谁来维护？ 团队没 Rust 经验就别上 Rust，维护成本比开发成本高。三问答完，选型基本只剩一个答案。

三问之外补一个否决项：任何选型都要能回退。先用现成采集器跑一个月，把真实痛点收集齐，再决定哪些痛点值得自研解决，比一开始就梭哈自研稳得多。回退的意思不只是「换回现成」，也包括自研失败时损失可控——先把边缘采集稳住，中心汇聚自研挂了也只是日志延迟，不会把业务拖下水。

POC 的最小清单

真要做 POC，给一张最小清单照着跑。素材：一周真实日志样本（含乱码、超长行、嵌套 JSON 各千分之一）；时长：24 小时连续灌入；观察指标：吞吐 TPS、内存与 CPU 峰值、丢弃条数、端到端延迟 P95、下游限速时的积压曲线。跑完这五项，选型的所有争论都能用数据收尾，而不是「我觉得」。

清单里最容易被跳过的是连续 24 小时：很多问题只在「内存涨了一夜」之后才出现，短时压测根本看不到。POC 还有一个隐藏收益：灌样本的过程会逼着把监控搭起来，而这套监控上线后正好继续用，不算白干。

语言选择：为什么是 Rust

如果决定自研，语言本身也值得一句。日志管道是典型的「CPU 轻微、IO 密集、内存敏感」负载：大量时间花在读写与序列化上， GC 停顿和运行时开销会被吞吐量放大。Rust 没有 GC，内存占用可预测，劣势是开发速度与团队学习曲线。Go 是折中：有 GC 但停顿可控、生态好、团队上手快。脚本语言适合做原型，扛高吞吐时资源占用先顶不住。结论很简单：吞吐和资源是硬约束选 Rust，上市速度是硬约束选 Go，本书选了前者并把代价（开发慢、调试手动）如实记录在后续各章。

不管选哪个，都把「语言不是核心竞争力、管道设计才是」刻在脑里：三线（吞吐、延迟、不丢）设计好了，语言只影响资源账单。顺带提一句迁移成本：一旦选定语言，后续插件、监控、运维工具都会围着它长，中途换语言等于重写一遍，所以第一年就用 POC 数据选准。

选型协议

最后给一个可落地的仪式：选型定下来后，写一张「选型协议」贴在 wiki 上，包含决策日期、决策人、三问答案、POC 数据、回退路径五项。半年后想推翻选型，先读这张协议——多半会发现当时的约束还在，不必要推翻；若约束真的变了，协议也成了新决策的起点，而不是一笔糊涂账。日志管道这种基础设施，最怕「每任负责人都重选一次」。

协议的精髓不在形式，而在于把「当时为什么这么选」固化下来。无数基础设施选型被推翻后又退回原状，全是因为没人记得第一次为什么选它。 写一张协议，半年省一场架构争吵。

踩坑提示

选型最大的坑是不做 POC 就拍板。benchmark 里现成采集器都很快，但灌入自己真实日志（带乱码、超长行、嵌套 JSON）时性能可能腰斩。建议拿一周真实日志样本做一次 24 小时 POC，同时盯资源占用与丢弃率两项。另一个坑是只看采集不看落库：采集器吞吐再高，下游写 COS 或 CLS 限速，积压照样发生，选型要端到端测。

小结

现成采集器胜在快和稳，自研胜在定制与资源。规则浅、目的端标准，选现成；规则深、跑业务机旁、资源敏感，自研或混合路线。无论怎么选，POC 一定要拿真实日志跑端到端，而不是看 benchmark 拍脑袋。

延伸阅读

• 汇聚层的通道与背压，见下一节 2.3。
• 资源占用压测方法，见 5.1。
• 边车与服务治理分层，见 Go 微服务实战。
• 日志归档与检索落盘，见 Node.js 云开发实战。
• 数据库侧冷热分表对照，见 MySQL 实战。