一、日志采集概述：为什么需要低延迟日志采集？
大家好，我是你们的老朋友。今天咱们聊聊日志采集，特别是低延迟场景下的那些事儿。
先问个问题：你见过系统出故障时，日志却迟迟刷不出来的情况吗？我见过。有一次线上服务突然雪崩，等了好几分钟日志才姗姗来迟。等看到日志时，故障现场早就没了。嗯，这就是典型的日志延迟问题。
1.1 为什么需要低延迟日志采集？
说白了，日志就是系统的「黑匣子」。飞机出事要看黑匣子，系统出问题要看日志。但黑匣子如果延迟几分钟才记录，那还有什么意义？
我总结了几类必须低延迟的场景：
- 故障定位：系统崩溃时，日志必须秒级可见。延迟超过10秒，现场就丢了。
- 安全审计：黑客攻击时，日志延迟意味着攻击者已经跑路了。
- 实时监控：业务指标依赖日志计算，延迟高了告警就成马后炮。
- 交易系统：金融场景下，日志延迟直接影响对账和合规。
核心观点：低延迟不是锦上添花，而是雪中送炭。没有低延迟，日志的价值至少打五折。
1.2 日志采集的挑战
你想想看，日志采集看起来简单——不就是写文件、发网络吗？但真正做起来，坑多着呢。
我遇到过最头疼的几个问题：
- 磁盘IO瓶颈：高并发下，日志写入直接拖垮业务线程。我曾经见过一个系统，日志写得太猛，业务QPS从1万掉到3000。
- 网络拥塞：日志数据量大，带宽被占满，业务数据反而传不过去。
- 数据丢失：为了追求低延迟，很多人选择异步写。但异步就意味着可能丢数据。怎么取舍？
- 格式混乱：不同团队用不同的日志格式，采集端解析起来想死的心都有。
避坑指南：我曾经在一个项目中，为了追求极致的低延迟，直接用了内存缓冲区+异步发送。结果服务重启时，缓冲区里的日志全丢了。那次教训让我明白：低延迟不能以牺牲可靠性为代价。
1.3 日志采集的目标
做低延迟日志采集，目标其实很明确：
| 目标维度 | 具体要求 | 我的经验值 |
|---|---|---|
| 延迟 | 端到端延迟 < 1秒 | 99%场景下做到500ms以内 |
| 吞吐量 | 单机支持10万+ TPS | 我见过最高到50万TPS |
| 可靠性 | 数据丢失率 < 0.01% | 最好做到万无一失 |
| 资源消耗 | CPU < 5%，内存 < 200MB | 不能影响业务进程 |
这几个目标其实是互相矛盾的。延迟低，往往意味着资源消耗高；吞吐量大，又可能影响可靠性。怎么平衡？这就是咱们这门课要讲的核心。
1.4 整体架构概览
我习惯把日志采集分成三层：
- 采集层：负责从业务进程捞日志，做初步处理
- 传输层：负责把日志从采集端送到存储端
- 存储层：负责持久化和索引
下面这张图，是我自己画的一个简化版架构：
个人经验：我建议你在设计采集层时，一定要考虑「背压」机制。就是当传输层或存储层扛不住时，采集层要能自动降级。否则，日志会把业务进程拖死。我曾经吃过这个亏，后来加了背压，系统稳如老狗。
1.5 低延迟的核心原则
做了这么多年日志系统，我总结出几条铁律：
- 能异步就别同步：日志写入不能阻塞业务逻辑。用异步队列，哪怕丢几条也比卡死强。
- 能批量就别单条：单条发送效率极低。攒一批再发，吞吐量能提升10倍。
- 能压缩就别裸传：日志文本冗余度高，压缩后体积能减少70%以上。
- 能本地缓冲就别直接写网络：网络抖动是常态，本地缓冲能扛住瞬时高峰。
记住：低延迟不是靠某一个环节做到的，而是全链路优化的结果。从采集、传输到存储，每个环节都要抠细节。
1.6 本章小结
嗯，这一章咱们聊了为什么需要低延迟日志采集，也看了常见的挑战和目标。说白了，低延迟日志采集就是一场与时间的赛跑。跑赢了，你就能在故障发生的第一时间拿到线索；跑输了，就只能事后诸葛亮。
下一章，我会带你深入采集端的实现细节，看看怎么用C++写一个高性能的日志采集器。到时候咱们再细聊。