尧图网站建设 
用 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 为核心系统讲解 REDRate/Errors/Duration与 USEUtilization/Saturation/Errors两种业界主流监控方法论并给出完整可复制的 PromQL 查询、面板分层结构与各类型面板Stat、Time Series、Table的落地写法。读完你将能够从零设计一套兼顾请求健康度与资源压力的 Grafana 面板并将其与监控埋点、告警规则联动起来。一、方法论先行RED 与 USE 两种视角设计监控面板的第一步不是选图表而是明确监控对象是什么。monitoring-expert 技能将面板构建方法归纳为两类经典模型RED面向服务请求面向用户价值USE面向底层资源面向系统容量。方法关注对象核心指标适用场景REDServices服务/请求Rate、Errors、Duration业务接口、微服务 API 的健康度USEResources资源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 分钟窗口内每秒平均增量用来把单调递增的计数器转换成当前 QPSsum聚合所有实例/路由的速率得到服务整体的请求吞吐。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响应时长分布p95histogram_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.mdrate(..._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{modeidle}[5m])) * 100)node_cpu_seconds_total来自 Node Exportermodeidle选择空闲态的 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 technicaldashboards.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 定义 Counterhttp_requests_total、Histogramhttp_request_duration_seconds、Gaugeactive_connections、Summary 等指标注意命名规范单位后缀_seconds/_bytes/_total使用秒与字节而非 ms/KB指标名前缀加服务名采集层暴露/metrics端点Node.js 用register.contentTypePython 用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])等长窗口查询做容量趋势外推。八、快速参考速查表方法论选择方法FocusMetricsREDServicesRate, Errors, DurationUSEResourcesUtilization, Saturation, Errors面板类型与用途Panel TypeUse CaseStat单个 KPI 当前值Time Series随时间变化的趋势Heatmap延迟分布直方图可视化TableTop N、明细下钻Gauge当前值 vs 阈值总结一份合格的监控面板 RED 覆盖服务健康 USE 覆盖资源压力 四段式布局保证扫读效率 业务指标体现业务价值 与告警/压测联动形成闭环。将本文的 PromQL 模板与 dashboards.md、prometheus-metrics.md、alerting-rules.md 三份参考结合使用即可在既有监控体系上快速落地一套可解释、可下钻、可告警的生产级 Grafana 面板。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 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 为核心系统讲解 REDRate/Errors/Duration与 USEUtilization/Saturation/Errors两种业界主流监控方法论并给出完整可复制的 PromQL 查询、面板分层结构与各类型面板Stat、Time Series、Table的落地写法。读完你将能够从零设计一套兼顾请求健康度与资源压力的 Grafana 面板并将其与监控埋点、告警规则联动起来。一、方法论先行RED 与 USE 两种视角设计监控面板的第一步不是选图表而是明确监控对象是什么。monitoring-expert 技能将面板构建方法归纳为两类经典模型RED面向服务请求面向用户价值USE面向底层资源面向系统容量。方法关注对象核心指标适用场景REDServices服务/请求Rate、Errors、Duration业务接口、微服务 API 的健康度USEResources资源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 分钟窗口内每秒平均增量用来把单调递增的计数器转换成当前 QPSsum聚合所有实例/路由的速率得到服务整体的请求吞吐。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响应时长分布p95histogram_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.mdrate(..._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{modeidle}[5m])) * 100)node_cpu_seconds_total来自 Node Exportermodeidle选择空闲态的 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 technicaldashboards.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 定义 Counterhttp_requests_total、Histogramhttp_request_duration_seconds、Gaugeactive_connections、Summary 等指标注意命名规范单位后缀_seconds/_bytes/_total使用秒与字节而非 ms/KB指标名前缀加服务名采集层暴露/metrics端点Node.js 用register.contentTypePython 用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])等长窗口查询做容量趋势外推。八、快速参考速查表方法论选择方法FocusMetricsREDServicesRate, Errors, DurationUSEResourcesUtilization, Saturation, Errors面板类型与用途Panel TypeUse CaseStat单个 KPI 当前值Time Series随时间变化的趋势Heatmap延迟分布直方图可视化TableTop N、明细下钻Gauge当前值 vs 阈值总结一份合格的监控面板 RED 覆盖服务健康 USE 覆盖资源压力 四段式布局保证扫读效率 业务指标体现业务价值 与告警/压测联动形成闭环。将本文的 PromQL 模板与 dashboards.md、prometheus-metrics.md、alerting-rules.md 三份参考结合使用即可在既有监控体系上快速落地一套可解释、可下钻、可告警的生产级 Grafana 面板。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考