日志采集架构设计原则
做日志采集系统，说白了就是在钢丝上跳舞。数据量大了不能丢，流量突增不能崩，业务那边还天天盯着延迟看。我这些年踩过的坑，基本都跟这几个原则有关。
这一章我们一口气讲清楚五个核心原则：可靠性、可扩展性、低延迟、安全性、降级策略。它们不是孤立的，很多场景下得一起权衡。比如你要保证低延迟，可能就得牺牲一点可靠性；你想无限可扩展，复杂度肯定上去。
核心观点：这五个原则是日志采集架构的基石。任何系统设计，都是在它们之间找平衡点。没有完美方案，只有最适合你场景的方案。
1. 可靠性
可靠性是日志系统的命根子。数据丢了，后面的分析、监控、告警全都是空话。
我在项目中遇到过最惨的一次：Agent进程挂了，缓冲队列里的日志全没了。那次之后我彻底改了设计。
核心机制：
- ACK确认机制：数据到了下游，必须回ACK。没收到ACK就重试。我个人习惯配三次重试，间隔指数退避。
- 本地持久化缓冲：内存队列不安全。Agent要写本地磁盘做缓冲，进程重启能恢复。推荐用mmap或者LevelDB这种嵌入式存储。
- 端到端校验：不光要传过去，还得保证内容没坏。每条日志算个CRC32或者MD5，接收端校验。
工程建议：本地缓冲的磁盘目录，最好跟操作系统分区分开。我曾经见过磁盘写满导致系统挂掉的案例，用独立分区能隔离风险。
| 可靠性机制 | 常见实现 | 优缺点 |
|---|---|---|
| ACK确认 | TCP ACK/自定义协议ACK | 简单可靠，但增加RTT |
| 本地缓冲 | mmap、LevelDB、RocksDB | 抗进程重启，需要磁盘IO |
| 端到端校验 | CRC32、MD5、SHA | 保证数据完整性，有计算开销 |
| 重试机制 | 指数退避 + 最大重试次数 | 应对网络抖动，可能造成延迟 |
避坑指南：我曾经天真地以为Kafka能保证所有场景下的可靠性。后来发现，如果Producer端不配acks=all，数据在Leader切换时还是会丢。你想想看，这种细节卡两天调试都不一定能发现。
2. 可扩展性
日志量增长你是预料不到的。今天一天100GB，明天业务上线就冲到1TB。可扩展性不是做不做的问题，是必须一开始就规划好。
架构要点：
- 无状态采集层：Agent尽量做到无状态，只负责转发。这样加机器就能线性扩容。
- 分片与分区：不管是写入Kafka还是ES，数据必须做分区。我习惯按时间+业务ID做双级分区。
- 动态路由：采集端能根据下游负载动态切换目标。比如Kafka某个分区慢了，自动分流到其他分区。
- 水平扩展的传输层：中间传输层（比如Kafka或者Pulsar）要能加节点后自动Rebalance。
关键判断：如果你发现系统扩容需要改代码或者重启进程，那这个扩展性就是假的。真正的水平扩展应该是加机器、改配置、马上生效。
我记得做过一个项目，初期只配了3台Kafka Broker。半年后日志量翻了10倍，加节点到12台，整个过程零停机。这就是好的扩展性设计。
3. 低延迟
延迟分两种：端到端延迟和管道内延迟。实时监控系统对延迟敏感，离线分析则宽松一些。
降低延迟的手法：
- 批量与实时分离：对延迟敏感的日志走独立通道。批量日志照常攒批发送，互不影响。
- 异步非阻塞IO：Agent必须用异步IO模型。Java系的Netty、Go的goroutine都行。别用阻塞式读写。
- 内存零拷贝：数据从网卡到磁盘再到网卡，尽量减少内存拷贝次数。Kafka的零拷贝技术就是这个道理。
- 采样与降级：极端高并发下，对低优先级日志做采样，保证核心日志延迟。
| 延迟等级 | 典型场景 | 推荐策略 |
|---|---|---|
| 秒级 | 交易监控、故障告警 | 独立通道 + 异步IO |
| 分钟级 | 业务指标统计 | 小批量（100条/批） |
| 小时级 | 离线报表、审计 | 大批量（5000条/批）压缩传输 |
实战技巧：我曾经为了压到秒级延迟，把Agent的内存队列从ArrayList换成了环形缓冲区（Ring Buffer）。效果立竿见影，GC暂停从50ms降到5ms以下。
4. 安全性
日志里经常带敏感信息，比如用户ID、手机号、支付金额。安全措施不到位，出事就是合规事故。
安全防护体系：
- 传输加密：Agent到服务端必须走TLS/SSL。不要觉得内网就安全，我见过内网横向移动攻击的例子。
- 身份认证：每个Agent要有独立证书或。服务端验证通过才接收数据。
- 数据脱敏：在采集端或者传输过程中，对敏感字段做脱敏。比如用户手机号只保留后四位。
- 访问控制：日志数据的不同级别要对应不同的访问权限。线上日志不能随便导出。
重要提醒：千万别把日志系统的访问凭证硬编码在配置文件里。我见过有人把Kafka密码写在Agent的配置文件中直接推上Git，那场面...嗯，就不说了。
5. 降级策略
系统不可能永远不出问题。网络断了、磁盘满了、下游挂了，这些情况都得有预案。降级策略不是可有可无的东西，它决定了故障时你是优雅降级还是直接崩盘。
降级的三道防线：
- 本地缓存降级：下游不可用时，日志先攒在Agent本地磁盘。等链路恢复再回传。我习惯给本地缓存的大小设上限，防止撑爆磁盘。
- 采样降级：当系统压力超过阈值，自动降低采集频率或采样率。比如全量采集降到10%采样。
- 静默丢弃：实在扛不住了，丢弃最低优先级的日志。听起来很粗暴，但总比整个系统雪崩要好。
核心原则：降级策略要可观测、可配、可回滚。每个降级动作都要打日志，方便事后复盘。而且降级参数不能写死，得支持热更新。
我记得有个突发流量场景，Agent每秒要处理50万条日志。我预配的降级策略触发后，核心交易日志100%保留，非关键的业务日志自动降到5%采样。最后峰值扛住了，下游也没被打垮。你看，降级策略不是怂，是聪明。
工程建议：降级策略一定要做演练。我曾经在线上手动触发过一次降级，结果发现配置的阈值偏大，根本不会触发。那次之后我养成了定期演练的习惯。
这五个原则，每个拿出来都能讲一整天。但总结起来就一句话：好的日志采集架构，扛得住流量、丢不了数据、跑得够快、安全合规、出了事还能体面退场。你设计系统的时候，脑子里始终绷着这根弦就好。