监控系统架构设计与方案选型 —— 从"感知故障"到"洞察业务"

系列博客第 1 篇。本文回答三个问题：监控为什么必不可少？一套监控系统长什么样？开源方案怎么选？

---

一、为什么每个高可用系统都需要监控

我们开发软件时，最容易被忽略、却最致命的一环，就是可观测性（Observability）。

优秀的软件，一定是考虑了各类故障的发现和应对手段的。它们都内置了监控数据的暴露方法——无论是 /metrics 接口、日志文件，还是内部状态接口。

随着时代发展，监控的诉求也在演进：

阶段	诉求	关键词
1.0	及时感知系统出问题	告警
2.0	预知问题（趋势预测）	容量规划
3.0	给系统"把脉"、调优	性能分析
4.0	洞察业务、辅助决策	业务可观测

通过监控，我们不仅能知道"系统挂了没"，还能知道"系统什么时候会挂"“哪里需要优化”“业务今天涨了还是跌了”。

---

二、监控领域的"黑话"（行业术语）

进入监控圈子，先搞懂这些词，后面才不会一脸懵：

• 指标（Metric）：可量化的数值，如 CPU 使用率、请求数。分四类：
  • Counter（计数器）：只增不减，如请求总数
  • Gauge（仪表盘）：可增可减，如内存使用量
  • Histogram（直方图）：样本分布，如请求耗时分桶
  • Summary（摘要）：类似 Histogram，客户端计算分位数
• 时序数据库（TSDB）：为时间序列优化的存储，如 Prometheus、VictoriaMetrics、M3DB
• Exporter：把第三方系统指标转成 Prometheus 格式的中间件
• 采集器（Agent）：部署在目标机器上、主动采集并上报的进程，如 Node Exporter、Categraf、Telegraf
• 告警（Alert）：指标越过阈值后产生的事件
• 事件闭环：从告警产生 → 通知 → 处理 → 验证恢复 → 关闭的完整链路

---

三、Google 黄金信号（Golden Signals）

无论监控什么系统，都可以用 Google SRE 提出的四个黄金指标来兜底：

┌─────────────────────────────────────────────┐
│           Google 黄金指标                     │
├──────────┬──────────────────────────────────┤
│ 延迟      │ Latency   — 请求耗时              │
│ 流量      │ Traffic  — QPS / 吞吐量          │
│ 错误      │ Errors   — 错误率 / 失败数        │
│ 饱和度    │ Saturation — 资源使用率（CPU/内存）│
└──────────┴──────────────────────────────────┘

对应到应用层，业界还有一套 RED 方法：

• Rate（请求速率）
• Errors（错误数）
• Duration（请求耗时）

本系列实战中，Demo 应用就是按 RED + 黄金信号来埋点的。

---

四、典型监控系统架构

一个标准的监控系统长这样：

            ┌──────────────┐
            │   采集层      │  Exporter / Agent / 埋点
            │ (采集器)      │  Node Exporter, Categraf, JMX...
            └──────┬───────┘
                   │  Pull (Prometheus 主动拉) / Push (Agent 主动推)
            ┌──────▼───────┐
            │   存储层      │  TSDB (Prometheus / VictoriaMetrics)
            └──────┬───────┘
                   │
        ┌──────────┼───────────┐
   ┌────▼────┐ ┌────▼────┐ ┌────▼────┐
   │ 查询层   │ │ 告警层   │ │ 展示层   │
   │ PromQL  │ │ Alerting│ │ Grafana │
   │         │ │ Nightingale│        │
   └─────────┘ └────┬────┘ └─────────┘
                     │ 事件 → 通知(钉钉/邮件) → 自愈

核心要点：

1. 采集与存储分离：采集器只管采集，存储只管存，解耦才能水平扩展。
2. Pull vs Push：Prometheus 是 Pull 模式（主动去抓），Categraf/Telegraf 常是 Push 模式（主动推）。
3. 告警与展示解耦：Grafana 负责"看"，Alertmanager/Nightingale 负责"叫"。

---

五、10 大开源监控方案横评

为了解答"到底选哪个"，我整理了主流开源方案的对比：

方案	类型	采集	存储	告警	优点	短板
Zabbix	老牌全栈	Agent/Ping/SNMP	关系型DB	内置	开箱即用、模板丰富	时序查询弱、扩展性差
Prometheus	云原生标准	Exporter(Pull)	自带TSDB	Alertmanager	生态最旺、PromQL强	单机存储有限、无长存
Nightingale	告警增强	兼容Prom	对接TSDB	强	事件闭环、自愈	依赖底层TSDB
Grafana	展示层	多数据源	无	弱	可视化无敌	不是完整监控系统
VictoriaMetrics	TSDB	兼容Prom	自研	需配合	高压缩、高性能	需自配采集
InfluxDB	TSDB	Telegraf	自研	Kapacitor	写入快	云收费、生态小
Open-Falcon	老牌	Agent	自研	内置	国内成熟	社区停滞
Categraf	采集器	多协议	Push	无	国产、开箱指标多	较新
Thanos	Prom扩展	复用Exporter	对象存储	复用AM	长存、全局视图	架构复杂
M3DB	TSDB	多	自研	需配合	超大规模	运维重

选型建议（结论先行）

• 云原生 / K8s 环境 → Prometheus + Grafana + Alertmanager
• 需要强大告警闭环 → 在 Prometheus 之上加 Nightingale 夜莺
• 机器多、指标杂、想要国产 → Categraf 采集 + Nightingale 管理
• 超长周期存储（>1年） → Prometheus + Thanos / VictoriaMetrics
• 传统运维 / 模板化监控 → Zabbix

本实战系列采用 Prometheus（采集+存储） + Nightingale（告警增强） + Grafana（展示） 的组合，兼顾生态成熟度与告警闭环能力。

---

六、本系列实战环境

为了把理论落地，我申请了 4 台华为云 FlexusX ECS（Ubuntu 24.04，8C16G）+ 1 台 atomcode 开发机：

角色	主机	公网 IP	部署组件
监控中心	ecs-0001	113.47.3.85	Prometheus / Grafana / Nightingale / Alertmanager
数据库节点	ecs-0002	1.94.204.215	MySQL 8.0 / Redis 7 + Exporter
消息/搜索	ecs-0003	124.71.228.177	Kafka 3.7 / ElasticSearch 8.13 + Exporter
应用节点	ecs-0004	113.44.133.102	Demo App / Categraf
开发机	atomcode	117.72.182.3	代码开发 / Git 推送

所有配置文件、安装脚本、仪表盘 JSON 均已开源在 Gitee：
https://gitee.com/LiaCin/monitoring-observability-practice

---

七、下一篇预告

第 2 篇：Prometheus 搭建与 PromQL 实战 —— 手把手在 ecs-0001 上从零搭建 Prometheus，配置 scrape，并用 PromQL 查询黄金指标。

---

本文为《运维监控实战》系列第 1 篇。实战代码与配置见 Gitee 仓库。