日志采集架构设计：采集节点、传输管道、中央存储、核心组件
做审计日志采集，说白了就是搭一条水管——源头拧开，中间别漏，末端装个大水箱。这套架构我折腾过好几套方案，从最开始的“脚本配cron硬推”到后来正经搞分布式采集，踩了不少坑。今天把这套架构拆成四块来讲：采集节点、传输管道、中央存储、核心组件。
1. 采集节点：数据的第一个触点
采集节点是日志诞生的地方。它可以是服务器、容器、网络设备、数据库实例，甚至是一个IoT传感器。采集节点上得有一个代理程序（Agent）来干三件事：发现日志文件、解析格式、打上元数据标签。
采集节点的核心职责有这几点：
- 可观测性：Agent自己得暴露指标——采集速率、丢弃率、延迟、轮转次数。否则你都不知道它到底是停了还是挂了一夜没干活。
- 断点续传：一旦采集进程崩溃，重启后得能从上次读到的偏移量继续，不能从头重新扫。我见过一个同事没有用偏移量管理，每天凌晨4点重启Agent，结果每天重复采集30GB历史日志，存储直接炸了。
- 低资源消耗：采集节点往往是业务机器，你不能因为采集日志把业务进程挤死。CPU使用率长期控制在1%以内，内存占用控制在50MB以内。
- 安全写入：Agent不能破坏原始日志文件，不能加锁，不能写回。只读，复制，然后上传。
2. 传输管道：数据怎么从节点到存储
传输管道是最容易出幺蛾子的环节。我参与过的项目里，70%的日志丢失问题都出在管道上，而不是采集端。
传输管道常见的选择：
| 方案 | 优点 | 缺点 |
|---|---|---|
| Kafka | 高吞吐、持久化、支持分区重试 | 运维成本高、需要ZooKeeper/Raft |
| HTTP/HTTPS推送 | 简单直接、防火墙友好 | 无缓冲、吞吐受限、重试逻辑自己写 |
| 文件传输（SFTP/rsync） | 可靠、离线友好 | 实时性差、不适合高频日志 |
| 消息队列（RabbitMQ, Pulsar） | 灵活性高、多语言SDK | 需要额外组件、延迟略高 |
我个人比较推荐用Kafka做主干管道，尤其是日日志量超过1TB的场景。原因很简单——Kafka天生支持多消费者、分区顺序保证、以及磁盘持久化。有一次生产环境，后端存储集群挂了40分钟，Kafka里的日志愣是一行没丢，恢复了之后Agent自动续传，业务方甚至没感觉到异常。
3. 中央存储：既是终点，也是起点
中央存储不只是一个“存日志的地方”。它决定了你能多快地查日志、能保留多久、成本有多高。
常见的中央存储方案：
- Elasticsearch：适合搜索和可视化，但写放大严重，建议搭配冷热分层。
- ClickHouse：写性能和压缩比出色，适合长周期统计查询，我手头一个集群每天写入600亿行，查询P99还在100ms以内。
- 对象存储（S3/MinIO）：成本极低，适合冷备和长期合规保留，但不适合实时查询。
- HDFS/大数据平台：适合批处理场景，但写入延迟较高，不适合实时告警。
建议策略：热数据存ClickHouse（7天），温数据存Elasticsearch（30天），冷数据降级到S3（6个月+）。这样既能保证查询性能，又能控制成本。我见过一家公司全量日志都塞Elasticsearch，结果每天光存储费用就够买一台宝马了。
4. 核心组件：让整个管道跑起来的幕后功臣
除了采集节点、传输管道、中央存储之外，还有几个关键组件不可或缺：
- 配置管理中心：统一管理采集策略、过滤规则、目标地址。我习惯用Apollo或Consul推配置，不用手动改每台机器的config文件。
- 监控告警模块：管道各个环节的健康状态、积压情况、异常事件必须有监控。例如：如果Kafka积压超过10万条，马上告警。
- 元数据索引：记录每条日志的来源、类型、时间戳、采集节点等标签。没有元数据，查日志就像在沙漠里找一粒沙子。
- 清洗转换引擎：在数据落盘之前进行字段提取、脱敏、格式标准化。我建议在管道中间加一层轻量级流处理（比如Flink或StreamSets），不要在生产Agent上做复杂转换。
这四块组件合起来就是一套完整的采集架构。你看，核心流程其实不复杂——采集节点负责产数据，传输管道负责搬数据，中央存储负责存数据，核心组件负责管控数据。但每一步都要设计好容错、监控和性能。
架构总览图
下面这张图把这四层的关系画了出来。你想想看，日志就是从左边采集节点出发，经过管道，最终落到右边存储里，中间还有核心组件在协调。
嗯，这套架构图我画过很多版本，这个是最简版——只保留了最关键的四层。你实际落地的时候，每层内部还会有更细的分工。举个例子，传输管道里我一般会放一个“缓冲层”（比如Kafka的topic分区数调整、生产者acks设置），中央存储里还得考虑数据生命周期管理和索引策略。这些细节后面几章会展开。