用 RED 与 USE 方法论构建 Prometheus/Grafana 监控面板：claude-skills monitoring-expert 实战指南-迪斯科星球

用 RED 与 USE 方法论构建 Prometheus/Grafana 监控面板：claude-skills monitoring-expert 实战指南

【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills

监控面板不是图表的堆砌，而是一套围绕"如何判断服务健康"组织起来的信息架构。本指南以 claude-skills 仓库中 monitoring-expert 技能的 dashboards.md 为核心，系统讲解 RED（Rate/Errors/Duration）与 USE（Utilization/Saturation/Errors）两种业界主流监控方法论，并给出完整可复制的 PromQL 查询、面板分层结构与各类型面板（Stat、Time Series、Table）的落地写法。读完你将能够从零设计一套兼顾请求健康度与资源压力的 Grafana 面板，并将其与监控埋点、告警规则联动起来。

一、方法论先行：RED 与 USE 两种视角

设计监控面板的第一步不是选图表，而是明确"监控对象是什么"。monitoring-expert 技能将面板构建方法归纳为两类经典模型：RED面向"服务请求"（面向用户价值），USE面向"底层资源"（面向系统容量）。

方法	关注对象	核心指标	适用场景
RED	Services（服务/请求）	Rate、Errors、Duration	业务接口、微服务 API 的健康度
USE	Resources（资源）	Utilization、Saturation、Errors	主机、数据库、中间件的容量压力

在 monitoring-expert 核心工作流中，面板可视化处于第五步之前的关键位置：先Assess（识别 SLI 与关键路径）→Instrument（埋点采集指标）→Collect（配置 Prometheus 拉取并验证数据）→ 再Visualize（用 RED/USE 方法构建面板）→ 最后Alert（设定阈值告警）。也就是说，面板是建立在正确埋点之上的——面板里每一条 PromQL 都需要上游存在对应的指标，这部分会在下文"与指标埋点衔接"中展开。

二、RED 方法：从请求视角回答"服务快不快、稳不稳"

RED 由 Tom Wilkie 提出，分别对应三个请求级问题：

Rate - Requests per second（每秒请求量，反映流量规模） Errors - Failed requests per second（每秒失败请求量，反映质量） Duration - Response time distribution（响应时间分布，反映体验）

2.1 Rate（请求速率）

sum(rate(http_requests_total[5m]))

http_requests_total是一个Counter 型指标（只增不减的累计计数），其埋点定义可见 prometheus-metrics.md 中的httpRequestsCounter 示例；
rate(x[5m])计算 5 分钟窗口内每秒平均增量，用来把单调递增的计数器转换成"当前 QPS"；
sum聚合所有实例/路由的速率，得到服务整体的请求吞吐。

2.2 Errors（错误率）

sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

通过标签选择器status=~"5.."精确匹配所有 5xx 状态码（5xx 共 100 种，用5..正则一次覆盖）；
分子为 5xx 错误速率，分母为总请求速率，两者相除得到错误率，这是 SRE 最核心的可用性指标之一；
该表达式与 alerting-rules.md 中HighErrorRate告警的 PromQL 完全同源，只是面板用于观察趋势、告警用于阈值触发。

2.3 Duration（响应时长分布，p95）

histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

http_request_duration_seconds_bucket来自Histogram 型指标（httpDuration），其桶边界在埋点阶段定义，例如buckets: [0.05, 0.1, 0.3, 0.5, 1, 2, 5]（见 prometheus-metrics.md）；
rate(..._bucket[5m])把累积桶计数转为速率；
histogram_quantile(0.95, ...)从桶分布中估算 p95 分位数，即"95% 的请求在多少毫秒内完成"。

三、USE 方法：从资源视角回答"机器扛不扛得住"

USE 由 Brendan Gregg 提出，聚焦资源而非请求，适合监控 CPU、内存、磁盘、网络：

Utilization - % time resource is busy（资源忙碌时间占比） Saturation - Queue depth, backlog（排队深度/积压程度） Errors - Error events（错误事件数）

3.1 CPU Utilization（利用率）

100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

node_cpu_seconds_total来自 Node Exporter，mode="idle"选择空闲态的 CPU 累计时间；
rate(..., [5m])计算空闲时间占比，再用100 -反转为利用率；
该表达式与 alerting-rules.md 中HighCPUUsage告警同源，告警版会额外加by(instance)按主机拆分。

3.2 Memory Saturation（内存饱和）

node_memory_SwapTotal_bytes - node_memory_SwapFree_bytes

用"已使用的 Swap 字节数"作为内存饱和度的代理指标——Swap 用量持续增长通常意味着物理内存不足、系统开始换页；
这类表达式是瞬时值计算，适合画成时序曲线或 Stat 面板观察趋势。

3.3 Disk Errors（磁盘错误）

rate(node_disk_io_time_weighted_seconds_total[5m])

计算磁盘 IO 时间加权的速率，反映磁盘层承受的 IO 压力与潜在错误趋势；
同样来自 Node Exporter 的指标族，与 3.1、3.2 一起组成基础设施面板的"压力三角"。

四、面板结构：四段式分层信息架构

有了指标，还需要把图表组织成一屏之内可扫读的布局。dashboards.md 给出了一套经过实战验证的四段式结构，从上到下依次为"总览 → 请求 → 延迟 → 基础设施"：

┌─────────────────────────────────────────────────────────────┐ │ SERVICE OVERVIEW │ │ Request Rate │ Error Rate │ p50 Latency │ p99 Latency │ ├─────────────────────────────────────────────────────────────┤ │ REQUEST METRICS │ │ [Graph: Requests/s by endpoint] │ │ [Graph: Error rate over time] │ ├─────────────────────────────────────────────────────────────┤ │ LATENCY METRICS │ │ [Heatmap: Latency distribution] │ │ [Graph: p50, p95, p99 over time] │ ├─────────────────────────────────────────────────────────────┤ │ INFRASTRUCTURE │ │ CPU │ Memory │ Disk │ Network │ └─────────────────────────────────────────────────────────────┘

设计原则可总结为三条：

首屏即结论：SERVICE OVERVIEW 一行四个 Stat 面板（QPS、错误率、p50、p99）让值班人员 3 秒内判断服务是否健康；
逐层下钻：从宏观速率到错误细节、再到延迟分布与底层资源，观察者按"先看有没有事，再看哪里有事"的顺序扫读；
方法分区：REQUEST METRICS 与 LATENCY METRICS 属于 RED 视角，INFRASTRUCTURE 属于 USE 视角，两者互补不重复。

五、三类核心面板的 PromQL 模板

dashboards.md 针对 Grafana 最常见的三种面板类型给出了可直接套用的模板。以下指标均假设已按 SKILL.md 的埋点示例完成采集（http_requests_total、http_request_duration_seconds）。

5.1 Stat Panel（单值统计）

适合放"当前时刻的唯一数字"，如 KPI 大屏或概览行：

# 当前 RPS sum(rate(http_requests_total[5m])) # 错误百分比 sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100

第二条在 RED 错误率的基础上乘以 100，把比率转成百分比展示。Stat 面板建议配合 Grafana 的阈值着色（如 >5% 变红），与后续告警阈值保持一致。

5.2 Time Series（时序曲线）

适合观察随时间变化的趋势，尤其适合多分位数叠加：

# 按状态码拆分请求速率 sum by (status) (rate(http_requests_total[5m])) # 延迟分位数组：p50 / p95 / p99 histogram_quantile(0.50, rate(http_request_duration_seconds_bucket[5m])) histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

sum by (status)按状态码标签分组聚合，一条曲线一个状态类别，异常状态一目了然；
三个分位数表达式画在同一张图上，可直观看到 p50 与 p99 的"长尾差距"，差距拉大往往意味着存在慢请求毛刺。

5.3 Table（表格）

适合展示 Top N 明细，定位"问题集中在哪个接口"：

# 按错误率排序的前 10 个接口 topk(10, sum by (path) (rate(http_requests_total{status=~"5.."}[5m])) / sum by (path) (rate(http_requests_total[5m])) )

sum by (path)先按路径维度各自计算错误速率与总速率；
相除得到每个路径的错误率，topk(10, ...)只保留错误率最高的 10 条记录——这是故障定位时最常用的下钻表。

六、业务指标面板：让监控面向业务价值

技术指标只能说明"系统在工作"，业务指标才能说明"系统在创造价值"。SKILL.md 的 MUST DO 清单中明确要求"Monitor business metrics, not just technical"，dashboards.md 给出了三个典型模板：

# 每分钟订单数 sum(rate(orders_created_total[5m])) * 60 # 最近 1 小时收入（前提：应用侧埋点） sum(increase(order_value_dollars_sum[1h])) # 活跃用户数（gauge 型指标） active_users_total

要点说明：

orders_created_total是业务型 Counter，在 prometheus-metrics.md 中有对应的ordersCreated埋点定义，标签可含status、payment_method等维度；
order_value_dollars_sum对应 Histogram 型指标orderValue（桶边界[10, 50, 100, 500, 1000]），increase(...,[1h])计算 1 小时增量；
active_users_total是 Gauge 型指标，反映"当前时刻"的在线人数，直接展示即可。

七、面板与埋点、告警的闭环联动

面板并非孤立的图表集，它在 monitoring-expert 的完整可观测链路中处于"可视化"环节。从本技能的其他参考文档可以勾勒出完整的数据流：

埋点层：按 prometheus-metrics.md 定义 Counter（http_requests_total）、Histogram（http_request_duration_seconds）、Gauge（active_connections）、Summary 等指标，注意命名规范（单位后缀_seconds/_bytes/_total，使用秒与字节而非 ms/KB，指标名前缀加服务名）；
采集层：暴露/metrics端点（Node.js 用register.contentType，Python 用generate_latest()），由 Prometheus 拉取后即可被面板查询；
面板层：用本文的 PromQL 模板完成可视化，例如histogram_quantile系列在面板中显示为延迟曲线，在 alerting-rules.md 的HighLatency告警中则作为阈值判定条件——同一表达式两个用途；
告警层：面板观察到的"错误率高于 5% 且持续 5 分钟"对应HighErrorRate规则，for字段消除瞬时抖动，annotations提供人类可读的告警内容。

面板还能与负载测试形成闭环：通过 performance-testing.md 的 k6/Artillery 脚本制造压力，同时观察面板上的 RED/USE 曲线，即可验证 p95 延迟目标（如<500ms）、错误率目标（如<1%）是否达标，并借助 capacity-planning.md 中的rate(http_requests_total[30d])等长窗口查询做容量趋势外推。

八、快速参考速查表

方法论选择

方法	Focus	Metrics
RED	Services	Rate, Errors, Duration
USE	Resources	Utilization, Saturation, Errors

面板类型与用途

Panel Type	Use Case
Stat	单个 KPI 当前值
Time Series	随时间变化的趋势
Heatmap	延迟分布（直方图可视化）
Table	Top N、明细下钻
Gauge	当前值 vs 阈值

总结

一份合格的监控面板 = RED 覆盖服务健康 + USE 覆盖资源压力 + 四段式布局保证扫读效率 + 业务指标体现业务价值 + 与告警/压测联动形成闭环。将本文的 PromQL 模板与 dashboards.md、prometheus-metrics.md、alerting-rules.md 三份参考结合使用，即可在既有监控体系上快速落地一套可解释、可下钻、可告警的生产级 Grafana 面板。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析