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 → 拆分大盘:将不常用的细粒度面板移到独立子大盘并以链接方式跳转。