3.3 日志采集与缓冲传输
3.3 日志采集与缓冲传输
本节摘要：日志要从成千上万台机器的磁盘文件汇到一个中央仓，中间这段传输路决定了两件事：丢不丢、堵不堵。本节拆解日志采集的四种方式（Agent、Syslog、SDK、消息队列），并重点讲"缓冲队列为什么是你日志体系的安全带"——采集端崩了、存储堵了、网络抖了，为什么日志还能兜住。
传输路决定你是"漏了几行"还是"丢了半天"
有一种失败最可怕：系统崩了，你用日志复盘，却发现故障那半小时的日志刚好没送到中央仓。不是没打，而是传输路上丢了。这比"没有日志"还坑——你会觉得"我看过日志了，什么都没有"，误导你把根因查向错误方向。所以采集与传输的设计目标就一条：尽量少丢，丢了也要让你知道丢了。
四种采集方式
Agent 文件采集：最常见。在一个节点上跑一个采集进程（Filebeat、Fluent Bit、Promtail），它盯着日志文件，读到新追加的内容就推给后端（或中间队列）。优点是不改应用代码，文件还在就能采；风险是文件轮转太快、进程崩了会漏采一段。
Syslog 网络采集：由系统把日志通过 syslog 协议推给 syslog 服务端。适合网络设备、系统日志这些本身就用 syslog 的。它是 UDP 居多、可以不保证送达，所以重要日志别完全依赖它。
SDK 采集：应用里嵌日志 SDK，直接把日志以结构化方式发到采集端或队列。和指标的 SDK 同理，能拿最结构化最细腻的日志，但要改代码。适合核心业务路径，保证关键日志质量。
消息队列缓冲：严格说是传输的中间层而不是采集方式，但它是串联这些方式的枢纽。采集端把日志推给 Kafka 这类队列，后端消费端按自己的节奏去消费存储。队列是日志体系最贵的单品，也最值得买。
为什么缓冲队列是安全带
把上面四种方式都想一遍，会发现采集端和存储端的速度天生不对等：采集端一秒吐几万条，存储端索引一卡就堵。如果采集端直接推给存储，存储堵了，采集端只能阻塞或者丢包——要么拖垮采集所在的应用，要么丢日志。
秘诀就是中间塞一层缓冲队列：采集端只管把日志推进队列，消费者按自己的能力慢慢消费。这样：
- 存储抖动，采集端不受影响，日志在队列里攒着。
- 采集端在生产高峰爆量，队列能削峰填谷。
- 消费者坏了，队列里的日志不丢，重启后接着消费。
我把这条路画给你看——注意缓冲让两端解耦了。
队列吞吐与消费组的设计
上队列不是白上的，得设计消费够快。核心参数是吞吐与消费组：生产端要保证写入 Kafka 的吞吐足够，消费端要设计合理的消费者组来并行消费解析——多少个 partition 就大致配多少个并行消费者，否则消费速度跟不上，队列里积压越来越深。
我见过"加了个 Kafka 就万事大吉"的团队，结果消费端只有两个单线程 worker，高峰期队列积压了几百万条，内存暴涨在存储索引前就把自己搞挂。落点：队列能缓冲，但必须有健康的消费者来清空它，否则缓冲变泄洪。
采集可靠性金字塔
把可靠性从高到低排，你会清楚每条路的信任等级：
| 可靠性 | 方式 | 说明 |
|---|---|---|
| 高 | Agent + Kafka 队列 + 消费端 | 队列兜底、可重放，丢得最少 |
| 中 | Agent 直推存储（重试） | 简单，但存储堵时可能短暂丢 |
| 中低 | Syslog(UDP) | 大概率不丢，但不保证送达 |
| 低 | 不采集（只存本机文件） | 文件轮转就没了，谈不上集中 |
我的建议：核心业务的日志走"Agent + 队列"这条高可靠路径，成本多的是队列的运维，但换来的是复盘时"日志在"的底气。边缘业务可以先走直推，真丢了几次再考虑加队——资源花在刀刃上。
别让采集成为应用的拖累
采集虽是"旁路",但它长在业务进程边上，一旦写得差，会反过来拖垮主线。最常见的两个反例：一是阻塞式上传——采集线程把日志往存储推时如果同步等结果,存储抖动就会被传导回业务线程,这是最阴险的故障来源;正解是采集端异步化,推不上去就本地缓存重试,绝不在业务主线程里等。二是采样把精度丢没了——为了省流量在采集端就按比例丢日志,结果排查那笔倒霉请求时发现它根本没被采到;取舍原则是"采样可以,但只降噪音档位,不降关键信号",错误日志和关键请求全采,普通信息日志才采样。采集的目标是"改业务不难、加日志不慌",而不是让采集自己成为新的故障点。
这些原则拼成一句话:采集端别阻塞业务、别在源头乱丢日志,传输路尽量走带缓冲的可靠通道,再用积压计数把"丢了多少"变成可告警的信号。到这一步,日志才算真正安全地、可见地送到了中央仓——后面才谈得上存哪、查多快。
本轮关键词：日志丢失的信号
这轮补一个实操信号。日志系统的价值在"复盘时信得过"，所以一定要有"丢了多少"的可观测性，而不是默默丢。做法是给采集端和消费端都打上"cumulative processed counter"指标，如果采集端计数据远大于消费端已索引数，差值就是积压量。把积压量接到监控指标上（接着第二章的活），让"积压超过阈值"也能告警。这样你不仅知道日志有没有到，还知道在路上堵了多少、有没有可能漏。
本节要点回顾
- 传输设计目标：尽量少丢，丢了也要让你知道丢了。
- Agent 采集最常用：盯文件追加，不改代码。
- Syslog 适合系统/网络日志：UDP 不保证送达，重要日志别裸奔。
- SDK 采集最细致：结构化质量最高，但要改代码。
- 缓冲队列解耦两端：存储堵了采集不受影响，是日志体系安全带。
- 消费端必须健康：队列只能缓冲，得有足够消费者清空积压。
- 用积压计数自证：把采集与消费的差接成监控告警，别再默默丢日志。
日志安全送到中央仓了，接下来是"存哪、查多快"的问题。下一节讲集中化存储与索引模型——ELK、Loki、Splunk 三种路子到底各牺牲了什么换来了什么。