2. 监控体系架构设计：分层架构、数据流、核心组件

聊到监控体系架构，很多人一上来就堆工具。Prometheus 配 Grafana，再搭个 Alertmanager，完事。嗯，这种玩法在小规模环境里确实能跑，但一旦节点上了千，数据量到了 TB 级，你就会发现——整个系统像一锅粥。

我个人习惯，在设计监控体系之前，先画一张分层架构图。把每一层的职责划清楚，数据怎么流，组件怎么搭，心里才有底。今天我就带你过一遍这套架构，顺便聊聊我在项目中踩过的坑。

2.1 分层架构：各司其职

监控系统说白了就四层：采集层 → 传输与处理层 → 存储层 → 展示与告警层。每一层只干自己的事，层与层之间通过标准接口通信。这样做的好处是——哪一层出了问题，替换起来不伤筋动骨。

我记得有一次，公司想把采集端从 Telegraf 换成 Prometheus Exporter。因为采集层和传输层之间用了统一的 JSON 格式，底层存储完全没感知。换完只花了半天，业务零影响。这就是分层架构的魅力。

2.2 数据流：从采集到告警的完整链路

数据是怎么跑的？我画个简单的流程给你看：

1. 采集端（比如 node_exporter）每 15 秒抓一次 CPU、内存、磁盘指标。
2. 数据通过 HTTP Pull 或 Push Gateway 送到 Prometheus Server。
3. Prometheus 把数据写入 TSDB（时序数据库），同时根据规则计算告警。
4. 告警触发后，推给 Alertmanager，由它做去重、分组、静默。
5. 最终告警通过 Webhook 发到钉钉、企微或邮件。
6. Grafana 从 Prometheus 查询数据，渲染成仪表盘。

你想想看，如果中间没有传输层做缓冲，采集端一多，Prometheus 直接扛不住写入压力。我在项目中遇到过，2000 台机器同时 Push 数据，Prometheus OOM 了三次。后来加了 Kafka 做缓冲队列，问题才解决。

2.3 核心组件详解

2.3.1 采集组件

采集层是监控系统的「眼睛」。选什么工具，取决于你监控的对象：

监控对象	推荐工具	采集方式
Linux 服务器	node_exporter	HTTP Pull
Windows 服务器	wmi_exporter	HTTP Pull
MySQL	mysqld_exporter	SQL 查询 + HTTP
Nginx	nginx_exporter + stub_status	解析状态页
网络设备	SNMP Exporter	SNMP Polling
自定义应用	Prometheus Client SDK	代码埋点

我个人习惯，能 Pull 就别 Push。Pull 模式让采集端无状态，扩容缩容都方便。但有些场景（比如短生命周期任务），Push Gateway 还是得用。

2.3.2 存储组件

存储层是监控系统的「大脑」。选型时主要看三点：写入吞吐、查询性能、数据压缩比。

• Prometheus TSDB：原生存储，单机部署简单，适合中小规模（百万级时间序列）。
• Thanos / VictoriaMetrics：Prometheus 的扩展方案，支持长期存储和高可用。
• InfluxDB：写性能极强，适合 IoT 和事件型数据。
• Elasticsearch：日志监控的首选，全文检索能力强。

2.3.3 告警组件

告警组件是监控系统的「嘴巴」。光有数据不行，得在出事时喊出来。

Alertmanager 是 Prometheus 生态的标配。它负责：

• 分组：把相似的告警合并成一条通知，避免告警风暴。
• 静默：维护窗口期，屏蔽已知问题。
• 路由：根据标签把告警发给不同的人或渠道。

举个例子，我曾经配置过一个规则：

groups:
- name: node_alerts
  rules:
  - alert: HighCpuUsage
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "{{ $labels.instance }} CPU 使用率超过 80%"

这个规则的意思是：CPU 使用率连续 5 分钟超过 80%，就触发 critical 告警。for 参数很重要，能过滤掉瞬时抖动。

2.3.4 展示组件

展示层是监控系统的「脸面」。Grafana 是目前最主流的方案，没有之一。

Grafana 支持多种数据源（Prometheus、InfluxDB、Elasticsearch、MySQL 等），拖拽式创建仪表盘。我个人习惯把仪表盘分成三层：

• 全局视图：展示整体健康状态，适合大屏。
• 服务视图：按业务线划分，展示关键指标。
• 实例视图：单台机器的详细指标，用于排查问题。

2.4 架构设计中的常见坑

最后，我总结几个我在项目中踩过的坑，你设计架构时注意避开：

• 采集端没有做认证：暴露的 /metrics 接口被外部扫描，数据泄露。记得加 basic_auth 或防火墙。
• 存储层没有做容量规划：Prometheus 默认保留 15 天数据，但没算磁盘增长。我建议按「每天 1GB/千台机器」估算。
• 告警规则写得太死：阈值设得太低，半夜告警轰炸。设得太高，故障了没通知。建议先用历史数据做基线测试。
• 展示层权限混乱：所有人都能改仪表盘，改完别人找不到了。用 Grafana 的团队和文件夹权限做隔离。

嗯，架构设计这块就聊到这儿。说白了，监控系统没有银弹，适合你业务场景的才是最好的。下一节我们聊聊具体的部署实战，到时候我会手把手带你搭一套完整的监控栈。

---

公众号:蓝海资料掘金营，微信 deep3321