| 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（导出文件）
- 截图（已上传或可访问）
- 文字描述的大盘结构
评审流程
按以下顺序执行：
- 采集大盘信息：优先调用
grafana-analyzer 技能拉取面板列表与截图；若仅有 URL，至少获取 dashboard_uid、panel 列表、变量列表。
- 分类映射：把每个面板归类为
Health Metric 或 Diagnostic Metric，找不到归类则标记为 Unclassified。
- 逐项检查：依据下文 §1 基础检查清单 + §2 进阶检查清单逐项判定 PASS / WARN / FAIL，并给出证据（panel 名 / 截图位置）。
- 模式比对：对照 §5 Good/Bad Case 模式库，识别常见反模式并标注。
- 量化打分：按 §3A 7 维度 24 细项给每项 0% / 50% / 100%，计算配置维度总分（满分 100）。如存在事故案例，再按 §3B 给事故视角分（满分 10）。
- 输出报告：按 §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 → 拆分大盘：将不常用的细粒度面板移到独立子大盘并以链接方式跳转。
