byted-sol-stability-grafana-dashboard-review

name	byted-sol-stability-grafana-dashboard-review
description	Grafana 监控大盘设计评审技能。基于"如何定义好的监控大盘"最佳实践，对一个 Grafana 大盘的设计或现状进行评审，输出问题清单、改进建议与有效性评分（满分 10 分）。触发词："/grafana-dashboard-review" 或用户要求"评审/审视/打分一个 Grafana 监控大盘"。
version	0.1.0

Grafana 监控大盘设计评审 Skill

适用场景

当用户提供一个 Grafana 大盘的链接、截图、JSON 配置或设计稿，要求"评审 / 评价 / 打分 / 检查 / 提改进意见"时使用本技能。

输入可以是以下任一形式：

• Grafana 大盘 URL
• 大盘 JSON（导出文件）
• 截图（已上传或可访问）
• 文字描述的大盘结构

评审流程

按以下顺序执行：

1. 采集大盘信息：优先调用 grafana-analyzer 技能拉取面板列表与截图；若仅有 URL，至少获取 dashboard_uid、panel 列表、变量列表。
2. 分类映射：把每个面板归类为 Health Metric 或 Diagnostic Metric，找不到归类则标记为 Unclassified。
3. 逐项检查：依据下文 §1 基础检查清单 + §2 进阶检查清单逐项判定 PASS / WARN / FAIL，并给出证据（panel 名 / 截图位置）。
4. 模式比对：对照 §5 Good/Bad Case 模式库，识别常见反模式并标注。
5. 量化打分：按 §3A 7 维度 24 细项给每项 0% / 50% / 100%，计算配置维度总分（满分 100）。如存在事故案例，再按 §3B 给事故视角分（满分 10）。
6. 输出报告：按 §4 报告模板输出 Markdown，必须包含细项打分明细、问题清单、改进路线图。

---

§1 基础检查清单（必查项，对应文档 1.1）

#	检查项	PASS 标准	常见 FAIL 模式
B1	Health vs Diagnostic 分区	顶部独立 Row 展示 Health，下方 Row 展示 Diagnostic，视觉上可区分（颜色/标题/Stat 面板）	全部混排；只有 Diagnostic；分区不清
B2	Health 指标告警配置	每个 Health 面板挂载告警规则 + 处理人 + 时效 ≤ 1min（按 SLA）	无告警；处理人空；告警延迟 > 1min
B3	Health 覆盖 SLI/RTO 场景	覆盖 RTO 场景列表 + 控制面（页面 PV/UV、核心 API VALET）+ 数据面（实例/集群/Job VALET）	仅有控制面或仅有数据面；RTO 场景未覆盖
B4	量+率组合告警	业务指标告警同时含量与率（如错误数 > N 且错误率 > x%），或采用智能监控	仅设单一阈值，导致小流量误报
B5	拨测覆盖小流量接口	流量不稳定的关键页面/API 引入拨测，且日常监控排除拨测流量	小流量接口无拨测；指标含拨测流量导致量级失真
B6	分层诊断指标	Diagnostic 至少包含：自身服务（吞吐/性能/容量）+ 强依赖 + 弱依赖 + 基础资源 + 事件（告警/变更）	只有自身服务；无依赖；无资源；无事件
B7	排查思路体现	Diagnostic 排列顺序与一般排查思路一致（自顶向下：业务→服务→依赖→资源）	随意堆叠，无层次
B8	客户维度筛选	大盘变量支持 account_id / 客户 ID 筛选；SVIP 有专属面板	不支持 account_id；无 SVIP 面板
B9	基础体验	已配置免登（权限可控）；URL 支持 region、account_id 等参数跳转；首屏包含关键 Health	必须登录才能访问；URL 不支持参数；首屏全是 Diagnostic

§2 进阶检查清单（加分项，对应文档 1.2）

#	检查项	说明
A1	告警/变更叠加	关键 Health 趋势图叠加告警事件、变更事件 annotation
A2	风险预警	设置接近事故阈值（非达标）的预警告警
A3	阈值贴合水位	阈值定期回归到日常水位附近，能感知缓慢恶化
A4	无数据告警	关键趋势图配置 no data 告警，避免指标跌零误判为监控故障
A5	例行变更指标治理	变更引起的"例行抖动"已被消除或屏蔽，避免麻木
A6	分位数优先于均值	延迟类指标使用 P95/P99，而非 avg；只有数据对称无离群时才用 avg

---

§3 大盘有效性评分模型

本节包含两套互补评分：§3A 配置维度量化评分（满分 100） 用于离线设计评审；§3B 事故视角评分（满分 10） 用于事后复盘。最终在报告中同时给出。

§3A 配置维度量化评分（满分 100）

本评分模型以"VCI 全局观测大盘 Good Case"为参考蓝本，覆盖 7 大维度 24 个细项；每个细项根据"完全满足 / 部分满足 / 未满足"分别给 100% / 50% / 0% 得分。

维度	权重	细项 ID	细项	满分	完全满足（100%）	部分满足（50%）	未满足（0%）
D1 首屏健康呈现	15	D1-1	红黄绿灯（潜在有损 / 承压预警 / 健康）三态呈现	5	红/黄/绿三态全用 Stat/Gauge 在首屏展示	仅二态或仅红绿	无颜色化健康灯
		D1-2	关键 SLI 损耗时间数字化	5	同时含「实例可用性 / 核心 API / 实例创删」损耗分钟数	仅 1–2 类 SLI	无损耗数字
		D1-3	首屏即可见可用率趋势图（含 SLO 红线）	5	趋势图叠加 SLO 阈值线	有趋势图但无 SLO 红线	首屏无可用率趋势
D2 指标覆盖度	25	D2-1	服务 SLI 覆盖（API 成功率 + 数据面连通性）	6	控制面+数据面 SLI 全覆盖且 SLO 标注	仅一侧	无 SLI
		D2-2	重点链路覆盖（创删、调度、磁盘 IO、端到端时延）	6	≥ 4 个核心链路均有 P90/P99	仅 2–3 个	≤ 1 个
		D2-3	核心依赖 QPS / 成功率 / P99（南向接口）	6	全部强依赖三件套齐全	仅 1–2 件套	无依赖监控
		D2-4	典型故障场景覆盖（Failed/Pending/IO hang/磁盘打满/物理机故障）	7	5 类全覆盖且对应面板可读	覆盖 2–4 类	≤ 1 类
D3 下钻定位能力	15	D3-1	健康 → 具体 API 下钻	5	一键跳转到 API 级 SLI 看板	需手动复制变量	无下钻
		D3-2	API → 用户/请求维度下钻	5	含 account 维度二级下钻	仅可看 TOP	无
		D3-3	异常 → 日志中心下钻	5	携带条件直达日志检索	需手动构造查询	无日志入口
D4 量+率组合	10	D4-1	同时呈现统计率（百分比）与统计量（绝对数字）	5	率与量并排展示	仅率或仅量	缺失
		D4-2	单点失败可发现（失败数、Terminating 列表等）	5	含失败实例列表 + 诊断按钮	仅总数	缺失
D5 客户/重点维度	10	D5-1	支持 account_id 任意筛选	4	模板变量可选所有客户	仅 TOP 列表	不支持
		D5-2	TOP 账号开关（聚焦重点客户）	3	提供"只看 top 账号"开关	仅静态 TOP	无
		D5-3	SVIP 专属重保大盘（链接 / 入口）	3	在快速跳转中提供 SVIP 大盘	仅文档说明	无
D6 事件与联动	15	D6-1	异动事件（告警 / 巡检失败）板块	5	大盘内嵌事件流	仅外链	无事件
		D6-2	关键变更事件叠加 / 发布观测	5	变更与指标叠加，可看影响	仅变更列表	无
		D6-3	快速跳转 / 联动看板	5	含 ≥ 3 个相关大盘跳转入口	仅 1–2 个链接	无
D7 数据质量与体验	10	D7-1	大盘数据准确无 NoData / 报错	4	全面板数据正常	局部 NoData	大量 NoData / 502
		D7-2	关键趋势图配置「无数据」告警	3	已配置	部分配置	未配置
		D7-3	免登 + URL 参数化跳转（region/account 等）	3	全支持	部分支持	必须登录 / 无参数

得分计算：总分 = Σ(每细项实得 × 权重占比)，向上按维度汇总。

等级：

• A 90+：可作为产品线样板（VCI Good Case 级）
• B 75–89：合格的产品大盘，少量改进项
• C 60–74：基本可用但缺关键能力
• D < 60：不合格，需重建

示例（VCI 全局观测大盘自评，参考 Good Case 文档）：

维度	得分 / 满分	说明
D1 首屏健康呈现	14 / 15	红黄绿灯齐全；CPU/MEM 仅数字未画趋势（D1-1 扣 1）
D2 指标覆盖度	18 / 25	SLI/重点链路/依赖齐全；典型故障覆盖 3/5（缺物理机故障、卡点阈值、限流）
D3 下钻定位能力	15 / 15	API → 用户 → 日志三级下钻完整
D4 量+率组合	10 / 10	创删失败数 + 可用率率并存
D5 客户/重点维度	9 / 10	TOP + account 全支持，SVIP 专属盘已提供
D6 事件与联动	9 / 15	跳转齐全；异动事件局部 NoData，发布观测大盘缺失
D7 数据质量与体验	7 / 10	局部 502 / NoData；无数据告警未全配
合计	82 / 100	B 级（接近 A）

§3B 事故视角评分（满分 10，对应原文档 §3.1）

维度	权重	评分细则
事故发现途径	2	大盘告警发现=2 / 人工观察=1 / 其他=0
指标可见性	2	首屏可见=2 / 翻页可见=1 / 不可见=0
数据准确性	2	准确=2 / 数据错=-1 / 数据缺失=-2
告警及时性	2	先于客户=2 / 延迟=-1 / 未告警=-2
是否用大盘定界	2	是=2 / 否=0

当用户未提供事故案例时，使用大盘当前配置回答"如果发生 RTO 场景事故，能否得分"作为代理打分，并在报告中标注 （基于配置推断）。

事故视角等级：A ≥ 8 优秀 ｜ 6 ≤ B < 8 良好 ｜ 4 ≤ C < 6 待改进 ｜ D < 4 不合格

---

§4 输出报告模板

# Grafana 大盘评审报告：<大盘名称>
- 链接：<URL>
- 评审时间：<YYYY-MM-DD>
- 配置维度评分（§3A）：<x>/100  等级：<A/B/C/D>
- 事故视角评分（§3B）：<y>/10  等级：<A/B/C/D>

## 一、整体结论
<2–3 句话给出核心判断，明确指出最大短板维度>

## 二、§3A 配置维度量化打分
| 维度 | 得分 / 满分 | 命中样板 / 反模式 | 关键说明 |
|---|---|---|---|
| D1 首屏健康呈现 | x / 15 | … | … |
| D2 指标覆盖度 | x / 25 | … | … |
| D3 下钻定位能力 | x / 15 | … | … |
| D4 量+率组合 | x / 10 | … | … |
| D5 客户/重点维度 | x / 10 | … | … |
| D6 事件与联动 | x / 15 | … | … |
| D7 数据质量与体验 | x / 10 | … | … |
| **合计** | **x / 100** | | |

## 三、细项判定明细（24 项，仅列出非满分项）
| 细项 ID | 细项 | 实得 / 满分 | 证据 | 改进建议 |
|---|---|---|---|---|
| D2-4 | 典型故障场景覆盖 | 3.5 / 7 | … | … |
| … | … | … | … | … |

## 四、§1 基础检查 / §2 进阶检查（可选辅以定性结论）
| # | 检查项 | 结果 | 证据 |
|---|---|---|---|

## 五、§3B 事故视角评分（如有事故案例）
| 维度 | 得分 | 依据 |
|---|---|---|
| 事故发现途径 | x | … |

## 六、问题清单（按风险排序）
1. **[High]** <问题，关联细项 ID + 命中反模式 BPx> —— 影响：<…>  建议：<…>
2. **[Med]** …
3. **[Low]** …

## 七、改进路线图（按优先级）
- **P0（≤ 2 周）**：<动作>  —— 预计提分 +x
- **P1（≤ 1 月）**：<动作>  —— 预计提分 +x
- **P2（季度内）**：<动作>  —— 预计提分 +x

---

工具协作

• 拉取面板/截图：调用 grafana-analyzer 技能（action=list_panels / export_only）。
• 阅读大盘 JSON：用 Read 工具读取本地导出的 JSON。
• 涉及告警规则查询时：可结合 Grafana API 或让用户粘贴告警配置。

输出原则

• 每条 FAIL/WARN 必须给出具体面板或区域的证据，避免笼统结论。
• 每条建议必须可执行，能落到"加面板 / 改阈值 / 加变量 / 加告警"等具体动作。
• 不臆造数据；信息缺失时在报告中明确标注"信息不足"，不直接给 PASS。

---

§5 重点产品线 Good/Bad Case 模式库

来源：《重点产品线监控大盘及告警配置梳理》第 3 章产品线大盘梳理。评审时如发现待评大盘命中下列模式，直接引用对应"反模式编号"或"样板编号"，提升评审说服力与一致性。

5.1 样板间（Good Cases，可作为参考蓝本）

编号	产品线	大盘	关键最佳实践
G1	VCI / VCI 业务全局观测	业务全局观测大盘	健康指标置顶、异常指标自动标红；服务指标支持下钻跳转；融合告警/巡检/变更事件；按入口流量/业务实例/核心链路/系统组件四层组织诊断指标；提供 TOP 账号筛选
G2	VPC 管控面	VPC API + xgw 数据面双盘	Health/Diagnostic 视觉分区清晰；首屏含 BGP 状态/资源 Quota/流量突变/拨测；TopN 节点 + TopN 账号下钻；秒级流量；依赖 DB/Redis/ETCD 全部纳入
G3	veDB（for MySQL）	veDB 大盘	控制面 + 数据面核心指标共同作为 Health；分组排列符合架构分层；包含实例/容量/依赖组件/基础设施完整分层；支持客户 ID 筛选
G4	RDS / MongoDB / Redis	各 SRE 大盘	通过基础资源监控覆盖"批量宕机"事故场景；提供独立的 OpenAPI 监控大盘；支持客户 ID 筛选；体现良好分层
G5	TOS（ToB 观测诊断）	TOS-ToB 业务观测诊断大盘	多组指标分别担任 Health；每组指标内部含多维度辅助诊断；覆盖读写请求、有效请求下跌、控制面请求
G6	VKE 用户资源使用	用户资源使用大盘	客户维度的容量/资源指标置顶为 Health；按节点池→关键节点→POD 三级展开诊断；事故预设丰富并被覆盖
G7	NAS（通用+缓存）	bytenas-for-user-tob	为重点客户配置专属面板，便于 SVIP 重保
G8	DAS / VPN	各产品大盘	把光模块、专线、EIP、IPSec、BGP 等强弱依赖组件指标全部纳入诊断层

5.2 反模式（Bad Cases，命中即标注扣分）

编号	反模式	典型现象	命中产品线（示例）	关联检查项
BP1	Health/Diag 不分区	大盘只有指标"分组"（MGR、数据库、JVM…），无法一眼看出业务是否出问题	Kafka、RabbitMQ、VKO、翻译大盘	B1
BP2	事故预设缺失或预设过窄	产品线无 RTO/事故预设；或预设只剩"物理机宕机"一项	APIG、VCI、PostgreSQL、CEN、Kafka、RabbitMQ	B3
BP3	大盘未覆盖事故预设	已有 RTO 场景但大盘未配监控（如 Kafka 物理机宕机）	Kafka、CR、VKE 部分场景	B3
BP4	缺失客户 ID 筛选	不能按 account_id 过滤，无法快速定位客户问题；无 SVIP 专属盘	Kafka、RabbitMQ、ECS（部分）、CLB	B8
BP5	大盘视图无数据/失效	加载报错、大量 NoData、变量过期	vePFS 运维侧/客户端、ECS 共享云大盘	A4 + 数据准确性
BP6	缺管控面 OpenAPI 监控	大盘只看数据面或运维面，控制面 API VALET 缺失	NAT、CLB、VKE、CR、APIG（部分）	B3
BP7	缺依赖组件监控	仅自身服务指标；上下游 DB/Redis/ETCD/光模块/专线等缺位	CLB、翻译大盘、CDP、HBase	B6
BP8	分层混乱、不体现排查思路	Diag 指标随机堆砌，无法自顶向下	HBase、MongoDB（部分）、CDP	B7
BP9	仅按 PSM 维度筛选	没有 region/AZ/cluster 等运维维度下钻	CDP	B8 + A1
BP10	指标数量爆炸、加载慢	面板过多过密，打开多个面板加载延迟	veDB（已知问题）	体验项

5.3 评审建议引用方式

在输出报告 §五（问题清单） / §六（改进建议） 中，建议显式引用：

• 命中反模式时：命中反模式 BP3：事故预设未被大盘覆盖（参考 Kafka 案例）
• 给改进建议时：参考样板 G2（VPC 管控面）的 Health/Diag 视觉分区方式
• 当产品线本身事故预设缺失时，先建议补全事故预设，再要求大盘覆盖（顺序不可颠倒）。

5.4 高频改进动作清单（可直接复制到报告）

按命中反模式自动推荐对应动作：

• BP1 → 在大盘顶部新增独立 Row「健康指标」，使用 Stat/Gauge 面板，红色阈值；其余指标下沉到「诊断指标」Row。
• BP2/BP3 → 同步产品线 RTO/事故预设清单，逐条核对大盘覆盖；事故预设缺失时同步补录至统一的故障等级定义文档。
• BP4 → 增加 account_id 模板变量；为 SVIP 客户复制一份专属大盘并预填 account_id。
• BP5 → 治理无数据面板：删除/修复数据源；为关键 Health 趋势配置 no data 告警。
• BP6 → 新增控制面 OpenAPI VALET（QPS、成功率、P99）面板，引用网关日志或 Action 维度指标。
• BP7 → 列出强/弱依赖清单（DB、Cache、MQ、ETCD、专线、光模块），逐个补诊断面板。
• BP8 → 按"业务→服务→依赖→资源"自顶向下重排 Row 顺序，并把 Row 标题改为有层次的树状（参考 VPC 大盘）。
• BP9 → 增加 region / AZ / cluster 维度变量并改写查询。
• BP10 → 拆分大盘：将不常用的细粒度面板移到独立子大盘并以链接方式跳转。