第二章：日志采集架构演进——从集中式到分布式，再到流式架构的演变
聊日志采集架构的演进，其实就是在聊我们这帮运维人怎么被业务逼着成长的。我入行那会儿，日志采集还是个挺简单的事儿，现在回头看，简直像石器时代。
2.1 集中式架构：一切从简，但扛不住
最早期的日志采集，说白了就是“一台机器搞定所有”。
架构大概长这样：
应用服务器 → 共享文件系统(NFS) → 日志分析服务器 → 存储所有应用服务器把日志写到同一个NFS挂载点，然后一台专门的服务器定时去扫这些文件，拉回来做分析。嗯，简单粗暴。
优点很明显：
- 部署简单，一个脚本搞定
- 管理方便，所有日志都在一个地方
- 适合小规模场景（几十台以内）
但坑也特别多：
- 单点瓶颈：NFS服务器一旦挂了，所有应用写日志都卡住。我遇到过NFS IO打满，导致业务线程阻塞，整个集群雪崩。
- 网络压力大：所有日志都走网络写到中央存储，带宽很容易被打满。尤其是业务高峰期，日志量能翻10倍。
- 实时性差：定时拉取通常是分钟级甚至小时级延迟，出问题了你得等半天才能看到日志。
2.2 分布式架构：分而治之，各管各的
集中式扛不住之后，大家开始想：为什么不把日志采集分散到每台机器上？
于是分布式架构出现了：
应用服务器 → 本地Agent → 消息队列(Kafka) → 消费端 → 存储每台机器上部署一个Agent（比如Filebeat、Fluentd），负责采集本机日志，然后统一发到Kafka这类消息队列里。下游的消费端再从Kafka拉数据，做后续处理。
这个架构解决了几个核心问题：
- 去中心化：每台机器自己采自己的，互不影响。一台挂了不影响其他。
- 削峰填谷：Kafka作为缓冲层，扛得住突发流量。我记得有一次双十一，日志量瞬间暴涨到平时的20倍，Kafka稳稳接住了。
- 可扩展：加机器就加Agent，加消费者就加分区，水平扩展无压力。
但分布式也不是银弹。你想想看，Agent本身也是进程，会占用CPU和内存。我见过有人把Agent配置成每秒采集10万条日志，结果Agent自己先OOM了。
2.3 流式架构：实时才是王道
分布式架构虽然解决了扩展性问题，但延迟还是不够低。为什么呢？因为从采集到写入存储，中间经过了Kafka、消费端、存储写入，每一步都有延迟。
对于实时监控、秒级告警这些场景，分钟级延迟根本没法忍。于是流式架构应运而生。
流式架构的核心思想是：日志从产生到消费，全程流式处理，不做批量落盘。
典型架构：
应用 → Agent(内存缓冲) → 流处理引擎(Flink/Spark Streaming) → 实时存储(Elasticsearch/ClickHouse)关键变化在哪？
- Agent层改用内存缓冲：不再写磁盘文件，而是直接写到内存队列，然后立即发送。延迟从秒级降到毫秒级。
- 流处理引擎实时计算：日志到了Kafka之后，Flink或Spark Streaming直接做实时聚合、过滤、告警，不需要等批处理。
- 存储层也追求低延迟：Elasticsearch的近实时搜索、ClickHouse的列式存储，都是为了让查询也能跟上节奏。
核心指标对比：
| 架构 | 端到端延迟 | 吞吐量 | 复杂度 |
|---|---|---|---|
| 集中式 | 分钟级~小时级 | 低（百MB/s） | 低 |
| 分布式 | 秒级~分钟级 | 中（GB/s） | 中 |
| 流式 | 毫秒级~秒级 | 高（10GB/s+） | 高 |
我个人习惯在流式架构里，把Agent的内存缓冲设成“有界队列”。比如最多缓存1000条，满了就丢弃旧数据。为什么？因为流式场景下，丢几条日志比阻塞整个管道要好得多。
2.4 三种架构的选型建议
你可能会问：那我到底该用哪种？
其实没有绝对的好坏，看场景：
- 小团队、机器少（<50台）：集中式够用，别折腾。但记得做好NFS的高可用。
- 中等规模（50~500台）：分布式是标配。Kafka+Filebeat的组合，我用了好多年，稳得很。
- 大规模（500台+）或对延迟敏感：上流式。但要做好运维复杂度飙升的心理准备。Flink的调优、Kafka的稳定性、ES的索引策略，每一个都是坑。
2.5 架构演进的核心逻辑（SVG图）
下面这张图，是我自己总结的日志采集架构演进脉络。从集中式到分布式，再到流式，核心驱动力就两个：规模和延迟。
嗯，这张图其实已经说得很清楚了。从集中式到分布式，核心驱动力是规模；从分布式到流式，核心驱动力是延迟。你想想看，如果你的业务只有几十台机器，日志延迟几分钟也无所谓，那集中式完全够用。但如果你在做实时风控、秒级监控，那流式架构就是必选项。
好了，这一章就聊到这儿。日志采集架构的演进，本质上就是业务倒逼技术升级的过程。下一章我们会深入Agent层的设计细节，聊聊怎么把采集延迟压到毫秒级。