尧图网页设计 
前面十四篇已从各方面详细介绍了 Promethues 本篇是 Prometheus 监控体系实战总纲只介绍三个问题本系列合起来是什么、每篇占什么位置、按什么顺序读最省力。本系列环境Prometheus v33.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_exporter3 ──┐ 应用层 Micrometer/Actuator4─┤ 入口层 nginx-exporter5 ──┼──► Prometheus Server 依赖层 blackbox-exporter6──┤ ├─ 目标管理服务发现2 业务层 sql-exporter7 ──┘ ├─ 规则计算方法收敛8 └─ 告警Alertmanager9 │ ▼ Grafana10→ 报告11 生产化底座高可用与长期存储12 安全与权限治理13 演进方向日志Loki链路Tempo统一采集OTel14本系列文章汇总篇标题回答的问题1Prometheus 监控体系全景与基础环境搭建三件套怎么用 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 段。参考链接Prometheus 官方文档https://prometheus.io/docs/Alertmanager 官方文档https://prometheus.io/docs/alerting/latest/overview/The RED MethodTom Wilkiehttps://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/USE MethodBrendan Gregghttps://www.brendangregg.com/usemethod.html Prometheus 监控体系实战：一张地图与三条路径
前面十四篇已从各方面详细介绍了 Promethues 本篇是 Prometheus 监控体系实战总纲只介绍三个问题本系列合起来是什么、每篇占什么位置、按什么顺序读最省力。本系列环境Prometheus v33.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_exporter3 ──┐ 应用层 Micrometer/Actuator4─┤ 入口层 nginx-exporter5 ──┼──► Prometheus Server 依赖层 blackbox-exporter6──┤ ├─ 目标管理服务发现2 业务层 sql-exporter7 ──┘ ├─ 规则计算方法收敛8 └─ 告警Alertmanager9 │ ▼ Grafana10→ 报告11 生产化底座高可用与长期存储12 安全与权限治理13 演进方向日志Loki链路Tempo统一采集OTel14本系列文章汇总篇标题回答的问题1Prometheus 监控体系全景与基础环境搭建三件套怎么用 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 段。参考链接Prometheus 官方文档https://prometheus.io/docs/Alertmanager 官方文档https://prometheus.io/docs/alerting/latest/overview/The RED MethodTom Wilkiehttps://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/USE MethodBrendan Gregghttps://www.brendangregg.com/usemethod.html