第一篇　需求与选型：日志管道难在哪

团队的服务越拆越多，日志却越来越难用：每个服务写本地文件，排障要登十台机器 grep，出一次故障眼睁睁看日志在屏幕上滚成瀑布。于是团队决定搭一根日志管道：把分散的日志统一收上来、压一压、存起来，再对接统一检索。

听起来无非是「读文件、转一发」，真做起来才发现到处是坑：吞吐上不去、高峰期日志被丢、采集进程把业务 CPU 吃光、改个配置还得重启全链路。本篇先把这根管道的难点拆清楚——吞吐、低延迟、不丢，再决定自研还是用现成采集器，最后把机器和存储地图对齐。配套的云产品是云服务器 CVM、云数据库 Redis、对象存储 COS 与日志服务 CLS，可参考 腾讯云 AI 数据处理平台 ADP 特惠。

本篇路线

为什么日志管道值得单独做

不少团队的答案是「上现成采集器得了」，这没错，但一旦遇到定制需求——比如按业务线分流、敏感字段脱敏、高峰期降级采样——现成工具的配置就会越堆越复杂，最后还是得写代码。自研一根小而精的管道，把这些规则收进自己的代码里，反而更可控。Rust 写这玩意的额外好处是资源占用低：同样吞吐，内存和 CPU 常常只有脚本语言方案的一半，跑在业务机旁边几乎无感。日志管道的完整落地可对照 Node.js 云开发实战 里的采集章节，思路互通。

延伸阅读

• 三条线的拆解，见下一节 1.1。
• 现成与自研的账，见 1.2。
• 机器与多进程，见 1.3。
• 组件地图与替代方案，见 1.4。