2. 数据采集架构设计：采集层、传输层、存储层、展示层的分层架构设计原则

聊到监控系统的数据采集架构，我见过不少团队一上来就堆组件，结果搞成了「蜘蛛网」。其实核心就四个字：分层解耦。把采集、传输、存储、展示拆开，每一层只干自己的活，出了问题也好排查。

我个人习惯把这种架构叫做「四层漏斗」——数据从采集端流进来，经过每一层过滤、加工，最后落到展示层。你想想看，如果哪一层出了问题，其他层还能继续跑，这就是分层最大的好处。

2.1 采集层：把数据「拽」出来

采集层是离数据源最近的一层。说白了，就是想办法把机器、容器、中间件、业务系统里的指标和日志给「掏」出来。

我在项目中遇到过最头疼的事：采集器把业务进程给拖垮了。有一次线上一个 Java 应用，因为采集 Agent 占用了太多 CPU，导致接口响应从 20ms 飙到了 2s。后来怎么解决的？限流 + 降级。采集器必须能自我约束，不能跟业务抢资源。

常见的采集手段就这几类：

• Agent 采集：部署在目标机器上，比如 Telegraf、Node Exporter
• SDK 埋点：嵌入业务代码，适合自定义业务指标
• 日志采集：Filebeat、Fluentd 监听日志文件变化
• 协议采集：SNMP、JMX、gRPC 等标准协议

2.2 传输层：数据的高速公路

采集层拿到数据后，不能直接往存储里塞。为什么？因为采集端和存储端的速度往往不匹配。采集是持续的、高频的，存储写入可能有瓶颈。这时候就需要一个「缓冲带」。

传输层最常用的就是消息队列。我个人偏爱 Kafka，吞吐量高、持久化好。但也不是非它不可——如果数据量不大，Redis List 或者 RabbitMQ 也能胜任。

传输层设计时要考虑三个点：

1. 可靠性：数据不能丢，至少一次语义（At-least-once）
2. 顺序性：同一台机器的指标尽量保持时序
3. 可扩展：加分区、加消费者就能水平扩容

2.3 存储层：数据怎么放、放多久

存储层是监控系统的「地基」。地基不稳，上面再花哨也没用。

我见过不少团队用 MySQL 存监控数据，结果一个月后磁盘就爆了。监控数据的特点是：写多读少、时序性强、数据量大。传统关系型数据库根本扛不住。

目前主流的方案分两类：

类型	代表产品	适用场景	注意点
时序数据库	Prometheus、InfluxDB、TimescaleDB	指标监控（CPU、内存、QPS）	注意数据保留策略（Retention）
全文搜索引擎	Elasticsearch	日志分析、链路追踪	索引生命周期管理（ILM）
列式存储	ClickHouse	大规模聚合查询	写入吞吐极高，但更新成本大

存储层有个原则叫「冷热分离」。热数据（最近 7 天）放在 SSD 上，冷数据（7 天以上）挪到 HDD 或者对象存储。我在项目里用 Prometheus 的 Thanos 组件做长期存储，效果还不错。

2.4 展示层：让数据「说话」

展示层是用户直接打交道的部分。数据采集得再好，展示得一团糟，业务方也不会买账。

展示层设计我总结了三个「不要」：

• 不要堆图表：一个页面放 50 个折线图，没人看得过来。聚焦关键指标。
• 不要忽略告警：展示层必须跟告警联动。数据异常了，图表上要有明显标记。
• 不要忘记权限：不同团队看不同的视图。我用 Grafana 的 Folder + Team 做隔离。

展示层常用的工具：

• Grafana：监控界的事实标准，支持 Prometheus、Elasticsearch、InfluxDB 等数据源
• Kibana：跟 Elasticsearch 配合，适合日志分析
• 自研 Dashboard：如果业务场景特殊，可以考虑用 ECharts 或 AntV 自己画

2.5 分层架构的「红线」

最后说几条我踩过坑后总结的红线：

1. 采集层不能依赖存储层：存储挂了，采集不能停。数据先放本地缓存，等恢复后再补发。
2. 传输层要有降级策略：消息队列满了怎么办？丢弃旧数据、降采样、或者直接走旁路。
3. 存储层要预留余量：磁盘使用率超过 80% 就要告警。我见过磁盘写满导致整个集群雪崩的惨案。
4. 展示层要关注延迟：从采集到展示，端到端延迟控制在 10 秒以内算合格，1 秒以内算优秀。

嗯，分层架构说白了就是「各司其职」。每一层做好自己的事，别越界。这样系统出了问题，你也能快速定位——是采集没上来？传输堵了？存储慢了？还是展示配置错了？

下一章我们聊聊具体的采集器选型，到时候我会拿 Telegraf 和 Prometheus Exporter 做个对比，看看实际项目中怎么选。

---