Prometheus 监控体系实战：一张地图与三条路径

鸿观工坊
0 阅读5分钟

前面十四篇已从各方面详细介绍了 Promethues ，本篇是 Prometheus 监控体系实战总纲，只介绍三个问题：本系列合起来是什么、每篇占什么位置、按什么顺序读最省力。

本系列环境：Prometheus v3（3.13.3 LTS）、Alertmanager v0.33.1、Grafana 13.0.7、Docker 27、Docker Compose 单机部署。

一、本系列在解决什么问题

监控项目的失败，很少因为"没采集"，通常是以下三种形态：

失败形态典型表现对应篇目
只采集，不收敛面板几百条曲线，出事时不知道先看哪条8
告警轰炸五分钟响 47 次，第七条开始被静音9
有面板，没闭环故障还是用户先发现的，影响面答不上来10、11

本系列的目标不是"装一个 Prometheus"，而是建成一个能转起来的闭环：采集（1~7）→ 方法收敛（8）→ 告警响应（9）→ 可视化呈现（10）→ 决策改进（11），高可用与安全（12、13）做生产化底座。

注意：评价一套监控体系，不看采集了多少指标，而是看这个闭环有没有转起来。只建"采集"和"告警"两条边，等于只建了半个闭环。

二、一张地图

整套体系分两个维度：指标从哪来（被监控对象分层）和指标怎么流转（平台能力分层）。

      指标从哪来（被监控对象）              指标怎么流转（平台能力）
      ────────────────────────            ──────────────────────────
      主机层  node_exporter（3）    ──┐
      应用层  Micrometer/Actuator（4）─┤
      入口层  nginx-exporter（5）   ──┼──► Prometheus Server
      依赖层  blackbox-exporter（6）──┤      ├─ 目标管理：服务发现（2）
      业务层  sql-exporter（7）     ──┘      ├─ 规则计算：方法收敛（8）
                                            └─ 告警：Alertmanager（9）
                                                   │
                                                   ▼
                                            Grafana（10）→ 报告（11）

      生产化底座：高可用与长期存储（12）＋ 安全与权限治理（13）
      演进方向：＋日志（Loki）＋链路（Tempo）＋统一采集（OTel）（14）

本系列文章汇总：

篇标题回答的问题
1​Prometheus 监控体系全景与基础环境搭建​三件套怎么用 Docker 拉起来
2Prometheus 服务发现：动态目标管理实战目标老在变，怎么不用手改配置
3主机层监控实战：node_exporter 核心指标与告警CPU、内存、磁盘、网络，看哪几个指标
4Spring Boot 应用监控：Micrometer 与 Actuator 实战JVM 与接口指标怎么暴露、怎么读
5Nginx 监控：流量、连接与性能指标8 个原生指标能回答什么、不能回答什么
6依赖服务探活：Blackbox Exporter外部视角看接口通不通、证书过没过期
7业务数据监控：SQL Exporter 与自定义业务指标数据库里的业务数字怎么变成指标
8关键指标分析方法：RED/USE 与黄金信号几百条曲线怎么收敛到十来条
9告警体系设计：Alertmanager 路由与告警治理响不响、响几条、响给谁
10Grafana 可视化进阶：变量、下钻与统一 Dashboard从 Overview 到根因的一条路
11监控报告编写：SLO/SLI 与数据分析方法影响多大、达标没有，怎么讲清楚
12Prometheus 高可用与长期存储单机的边界在哪、数据怎么存一年
13监控安全与权限治理监控系统自己怎么不被打穿
14从监控到可观测性：体系化总结与演进路线这套体系建成了什么、往哪长

1~7 篇解决“看得见”，8~11 篇解决“看得懂、用得上”，12~14 篇解决“扛得住、锁得住、往哪长”。

三、三条路径

从目标出发，有三条路径可选：

路径适合谁顺序说明
A. 把架子搭起来从零开始建监控1 → 3 → 4 → 5 → 6 → 7第 1 篇装骨架，第 3~7 篇按层接 exporter。第 2 篇先跳过——目标不到二十个时 static_configs 够用，手改配置开始烦了再回来
B. 让数据说话采集齐了，但没人看8 → 9 → 10 → 11先砍指标，再治告警，再整面板，最后补报告。这是多数团队真正缺的后半段闭环
C. 生产化准备上生产或扩规模2 → 12 → 13 → 14规模上来先做服务发现，再谈高可用，然后关安全这扇门，最后看演进

若是接手已有环境，建议从路径 B 开始：先判断现有指标值不值得看，再决定要不要动采集。

四、四条主线

本系列会从某一篇定下约定、后面再按约定消费。读之前记住，能省掉大量"为什么这里的 PromQL 长这样"的疑问：

主线内容定义于消费于
数据链路exporter → pull → TSDB → 规则 → Alertmanager → Grafana；排障先问 up 是不是 01全部
标签规范job / svc / type / env；改一次，下游规则悄悄失效且不报错28、9、10
方法论RED 管服务、USE 管资源、黄金信号兜底83~7、9
命名约定recording rule 用 level:metric:operations 冒号命名5全部

五、边界

  • 只做 Metrics 一根柱子。日志、链路、OpenTelemetry 属于可观测性的另外两根柱子，第 14 篇给出演进路线但不展开。
  • 不讲 kube-prometheus-stack。Kubernetes 内置监控是另一个专题，本系列只在第 2 篇触及 k8s 服务发现。
  • 默认单机起步。中小规模先把单机做对，比一上来就搭集群有价值；高可用在第 12 篇。
  • 版本锚定。大版本升级后个别配置项和指标名可能有出入，对不上先查版本差异。

六、小结

本套体系 = 分层采集 × 方法收敛 × 告警治理 × 可视化下钻 × 报告决策，外加高可用与安全两块底座。 14 篇不是 14 个知识点，是一个闭环的 14 段。

参考链接：

​

avatar
文章
阅读
粉丝