第一章：日志系统全景——为什么低延迟如此重要？
说实话，我做了十几年分布式系统，最怕的不是服务宕机，而是日志丢了。
你想想看，线上出了故障，你连现场回放都看不到，那才叫真正的抓瞎。今天咱们就来聊聊日志系统的全景，重点说说——为什么低延迟这么要命。
1.1 低延迟：日志系统的生命线
先问个问题：日志延迟 1 秒，意味着什么？
我遇到过这么个事。有一次线上支付服务突然超时飙升，我们查了 20 分钟才发现是数据库连接池被打满了。但日志系统延迟了 3 秒才把错误日志刷出来。就这 3 秒，影响了上千笔交易。
说白了，日志延迟就是故障发现的延迟。你晚一秒看到异常，可能就多损失几十万。
核心观点：日志系统的低延迟，直接决定了故障的 MTTR（平均修复时间）。延迟越低，你离真相越近。
那到底多低才算低？我个人习惯这么分：
| 场景 | 可接受延迟 | 理想延迟 |
|---|---|---|
| 业务交易日志 | < 1 秒 | < 100 ms |
| 系统监控日志 | < 5 秒 | < 1 秒 |
| 安全审计日志 | < 10 秒 | < 2 秒 |
| 调试/追踪日志 | < 30 秒 | < 5 秒 |
嗯，这里要注意：不是所有日志都需要毫秒级延迟。但核心业务链路，必须做到秒级以内。
1.2 日志系统的核心架构
一个完整的日志系统，说白了就四个环节：采集 → 传输 → 存储 → 检索。每个环节都可能成为瓶颈。
我画了张图，帮你快速理解整体脉络：
1.3 采集层：第一道关卡
采集层是日志系统的入口。这里最容易犯的错误，就是让日志采集拖慢了业务进程。
我曾经接手过一个项目，开发同学直接在业务代码里用 System.out.println 打日志，然后重定向到文件。结果高并发下，IO 直接打满，服务响应时间从 5ms 飙到了 200ms。
我的建议：采集端一定要用异步方式。Filebeat、Fluentd 这些工具，本质就是帮你把日志从业务进程里「偷」出来，不阻塞主流程。
采集层的关键指标就两个：
- 采集延迟：从日志产生到被采集器读取的时间
- 资源开销：CPU、内存、IO 不能影响业务
1.4 传输层：缓冲与削峰
传输层是日志系统的「高速公路」。没有它，采集和存储之间就是硬耦合，一堵全堵。
我习惯用 Kafka 做传输层。为什么？因为它能扛住突发流量。你想想看，双十一零点那波流量，日志量可能是平时的 100 倍。没有缓冲层，存储系统直接被打挂。
传输层要关注三个点：
- 吞吐量：每秒能处理多少条日志
- 持久性：消息会不会丢（Kafka 的 ack 机制）
- 顺序性：同一个业务的日志顺序不能乱
注意：Kafka 不是银弹。如果日志量不大（每秒几百条），用 Redis 或者直接 TCP 推送可能更简单。别为了用 Kafka 而用 Kafka。
1.5 存储层：写得快，查得也快
存储层是最纠结的一层。既要写得快（低延迟），又要查得快（检索性能）。
Elasticsearch 是目前的主流方案。它的倒排索引让全文搜索很快，但写入性能受限于分片数和 refresh 间隔。
我踩过一个坑：默认的 refresh 间隔是 1 秒，但业务要求日志写入后 500ms 内可查。我调成了 100ms，结果写入吞吐直接掉了 30%。后来怎么解决的？用 bulk 批量写入，配合适当的分片策略，才平衡了读写。
存储层的核心权衡：
| 策略 | 写入延迟 | 检索延迟 | 适用场景 |
|---|---|---|---|
| 实时写入（refresh 100ms） | 低（100ms） | 低 | 交易日志、监控告警 |
| 批量写入（refresh 5s） | 中（5s） | 低 | 业务日志、访问日志 |
| 离线写入（每小时） | 高（1h） | 中 | 审计日志、历史归档 |
1.6 检索层：最后一公里
检索层是用户直接面对的。延迟再低，查不到也白搭。
我个人习惯把检索分为两类：
- 实时检索：最近 1 小时的数据，要求秒级响应
- 历史检索：几天甚至几个月前的数据，可以接受分钟级
为什么这么分？因为 Elasticsearch 的索引是有成本的。保留太多热数据，查询会变慢。我一般用「冷热分离」策略：最近 3 天的数据放 SSD 热节点，更早的放 HDD 冷节点。
一句话总结：日志系统的低延迟，不是某一个环节的事。采集、传输、存储、检索，每个环节都要控制在秒级以内，才能做到真正的「实时可观测」。
好了，这一章咱们把日志系统的全景和低延迟的重要性聊透了。下一章开始，我会带你深入每个环节的实战细节——从采集端的坑开始讲起。