Applicable Scenarios
Use this skill when the user provides a link, screenshot, JSON configuration, or design draft of a Grafana dashboard and requests "review / evaluate / score / check / provide improvement suggestions".
The input can be any of the following forms:
- Grafana dashboard URL
- Dashboard JSON (exported file)
- Screenshot (uploaded or accessible)
- Text-described dashboard structure
Review Process
Execute in the following order:
- Collect dashboard information: preferentially call the
grafana-analyzerskill to fetch the panel list and screenshots; if only a URL is available, at minimum obtain dashboard_uid, panel list, and variable list. - Classification mapping: classify each panel as
Health MetricorDiagnostic Metric, and mark asUnclassified。 - Item-by-item check: based on the §1 basic checklist + §2 advanced checklist below, determine PASS / WARN / FAIL item by item, and provide evidence (panel name / screenshot location).
- Pattern comparison: compare against the §5 Good/Bad Case pattern library, identify common anti-patterns, and annotate them.
- Quantitative scoring: according to §3A's 7 dimensions and 24 sub-items, give each item 0% / 50% / 100%, and calculate the configuration dimension total score (out of 100). If incident cases exist, then according to §3B give the incident perspective score (out of 10).
- Output report: output Markdown according to the §4 report template, which must include the sub-item scoring details, issue list, and improvement roadmap.
§1 Basic Checklist (mandatory items, corresponding to document 1.1)
| # | Check Item | PASS Standard | Common FAIL Patterns |
|---|---|---|---|
| B1 | Health vs Diagnostic zoning | The top independent Row displays Health, and the lower Row displays Diagnostic, visually distinguishable (color/title/Stat panel) | All mixed together; only Diagnostic; zoning unclear |
| B2 | Health metric alert configuration | Each Health panel has an alert rule attached + owner + timeliness ≤ 1min (per SLA) | No alert; owner empty; alert delay > 1min |
| B3 | Health covers SLI/RTO scenarios | Covers the RTO scenario list + control plane (page PV/UV, core API VALET) + data plane (instance/cluster/Job VALET) | Only control plane or only data plane; RTO scenarios not covered |
| B4 | Volume + rate combined alerting | Business metric alerts contain both volume and rate (e.g., error count > N and error rate > x%), or use intelligent monitoring | Only a single threshold is set, causing false alarms for low traffic |
| B5 | Probing covers low-traffic interfaces | Key pages/APIs with unstable traffic introduce probing, and routine monitoring excludes probe traffic | Low-traffic interfaces have no probing; metrics include probe traffic, causing magnitude distortion |
| B6 | Layered diagnostic metrics | Diagnostic includes at least: own service (throughput/performance/capacity) + strong dependencies + weak dependencies + basic resources + events (alerts/changes) | Only own service; no dependencies; no resources; no events |
| B7 | Reflects troubleshooting approach | Diagnostic order matches general troubleshooting approach (top-down: business → service → dependencies → resources) | Randomly stacked, no hierarchy |
| B8 | Customer dimension filtering | Dashboard variables support account_id / customer ID filtering; SVIP has a dedicated panel |
account_id not supported; no SVIP panel |
| B9 | Basic experience | SSO configured (controllable permissions); URL supports region、account_id and other parameters for navigation; first screen includes key Health |
Login required to access; URL does not support parameters; first screen is all Diagnostic |
§2 Advanced checklist (bonus items, corresponding to document 1.2)
| # | Check item | Description |
|---|---|---|
| A1 | Alert/change overlay | Key Health trend charts overlaid with alert events and change event annotations |
| A2 | Risk warning | Set warning alerts close to incident thresholds (not meeting the standard) |
| A3 | Thresholds aligned with water level | Thresholds are periodically regressed to near daily water levels, enabling perception of slow degradation |
| A4 | No-data alert | Key trend charts configured with no data alerts, avoiding metrics dropping to zero being misjudged as monitoring failure |
| A5 | Routine change metric governance | "Routine jitter" caused by changes has been eliminated or masked, avoiding desensitization |
| A6 | Percentiles preferred over averages | Latency metrics use P95/P99 instead of avg; only use avg when data is symmetric with no outliers |
§3 Dashboard effectiveness scoring model
This section contains two complementary scoring sets:§3A Configuration dimension quantitative scoring (full score 100) used for offline design review;§3B Incident perspective scoring (full score 10) used for postmortem review. Both are given in the final report.
§3A Configuration dimension quantitative scoring (full score 100)
This scoring model uses the "VCI Global Observability Dashboard Good Case" as the reference blueprint, covering 7 major dimensions and 24 sub-items; each sub-item is scored 100% / 50% / 0% based on "fully satisfied / partially satisfied / not satisfied" respectively.
| Dimension | Weight | Sub-item ID | Sub-item | Full score | Fully satisfied (100%) | Partially satisfied (50%) | Not satisfied (0%) |
|---|---|---|---|---|---|---|---|
| D1 First-screen health presentation | 15 | D1-1 | Red/yellow/green light (potentially impaired / under pressure warning / healthy) three-state presentation | 5 | All three states red/yellow/green displayed on the first screen using Stat/Gauge | Only two states or only red/green | No colorized health light |
| D1-2 | Digitization of key SLI loss time | 5 | Includes loss minutes for "instance availability / core API / instance create-delete" at the same time | Only 1–2 types of SLI | No loss numbers | ||
| D1-3 | Availability trend chart visible on the first screen (including SLO red line) | 5 | Trend chart overlaid with SLO threshold line | Has trend chart but no SLO red line | No availability trend on first screen | ||
| D2 Metric Coverage | 25 | D2-1 | Service SLI coverage (API success rate + data plane connectivity) | 6 | Full coverage of control plane + data plane SLIs with SLO annotations | Only one side | No SLI |
| D2-2 | Key path coverage (create/delete, scheduling, disk IO, end-to-end latency) | 6 | All ≥ 4 core paths have P90/P99 | Only 2–3 | ≤ 1 | ||
| D2-3 | Core dependency QPS / success rate / P99 (southbound interfaces) | 6 | All strong dependencies have the full trio | Only 1–2 of the trio | No dependency monitoring | ||
| D2-4 | Typical failure scenario coverage (Failed/Pending/IO hang/disk full/physical machine failure) | 7 | All 5 categories covered with readable corresponding panels | Covers 2–4 categories | ≤ 1 category | ||
| D3 Drill-down Localization Capability | 15 | D3-1 | Health → specific API drill-down | 5 | One-click jump to API-level SLI dashboard | Manual variable copying required | No drill-down |
| D3-2 | API → user/request dimension drill-down | 5 | Includes second-level account dimension drill-down | Can only view TOP | None | ||
| D3-3 | Anomaly → log center drill-down | 5 | Carries conditions directly to log search | Query must be constructed manually | No log entry point | ||
| D4 Volume + Rate Combination | 10 | D4-1 | Presents both statistical rate (percentage) and statistical volume (absolute number) | 5 | Rate and volume displayed side by side | Only rate or only volume | Missing |
| D4-2 | Single-point failures detectable (failure count, Terminating list, etc.) | 5 | Includes failed instance list + diagnostic button | Only total count | Missing | ||
| D5 Customer/Key Dimensions | 10 | D5-1 | Supports arbitrary account_id filtering | 4 | Template variable can select all customers | Only TOP list | Not supported |
| D5-2 | TOP account toggle (focus on key customers) | 3 | Provides "view top accounts only" toggle | Only static TOP | None | ||
| D5-3 | SVIP dedicated priority assurance dashboard (link / entry point) | 3 | Provides SVIP dashboard in quick jump | Only documented | None | ||
| D6 Events and Linkage | 15 | D6-1 | Anomaly event (alert / inspection failure) section | 5 | Event stream embedded in dashboard | External link only | No events |
| D6-2 | Key change event overlay / release observation | 5 | Changes overlaid with metrics, impact visible | Only change list | None | ||
| D6-3 | Quick jump / linked dashboards | 5 | Includes ≥ 3 related dashboard jump entry points | Only 1–2 links | None | ||
| D7 Data Quality and Experience | 10 | D7-1 | Dashboard data accurate with no NoData / errors | 4 | All panel data normal | Partial NoData | Large amount of NoData / 502 |
| D7-2 | Key trend charts configured with "No data" alerts | 3 | Configured | Partially configured | Not configured | ||
| D7-3 | SSO-free + URL parameterized navigation (region/account, etc.) | 3 | Fully supported | Partially supported | Login required / no parameters |
Score calculation：总分 = Σ(每细项实得 × 权重占比), aggregated upward by dimension.
Grade：
- A 90+: Can serve as a product line model (VCI Good Case level)
- B 75–89: Qualified product overview, a few improvement items
- C 60–74: Basically usable but lacks key capabilities
- D < 60: Unqualified, requires rebuilding
Example (VCI global observability dashboard self-assessment, refer to Good Case document)：
| Dimension | Score / Full score | Description |
|---|---|---|
| D1 First-screen health presentation | 14 / 15 | Red/yellow/green lights complete; CPU/MEM are only numbers without trend charts (D1-1 deducts 1) |
| D2 Metric coverage | 18 / 25 | SLI/key links/dependencies complete; typical fault coverage 3/5 (missing physical machine faults, stuck-point thresholds, rate limiting) |
| D3 Drill-down localization capability | 15 / 15 | API → user → logs three-level drill-down complete |
| D4 Volume + rate combination | 10 / 10 | Create/delete failure count + availability rate coexist |
| D5 Customer/key dimensions | 9 / 10 | TOP + account fully supported, SVIP dedicated dashboard already provided |
| D6 Events and linkage | 9 / 15 | Navigation complete; anomaly events partial NoData, release observability dashboard missing |
| D7 Data quality and experience | 7 / 10 | Partial 502 / NoData; no-data alerts not fully configured |
| Total | 82 / 100 | Grade B (close to A) |
§3B Incident perspective scoring (full score 10, corresponding to original document §3.1)
| Dimension | Weight | Scoring rules |
|---|---|---|
| Incident discovery channel | 2 | Dashboard alert discovery=2 / manual observation=1 / other=0 |
| Metric visibility | 2 | Visible on first screen=2 / visible after page turn=1 / invisible=0 |
| Data accuracy | 2 | Accurate=2 / data error=-1 / data missing=-2 |
| Alert timeliness | 2 | Earlier than customer=2 / delayed=-1 / no alert=-2 |
| Whether dashboard is used for scoping | 2 | Yes=2 / No=0 |
When the user does not provide an incident case, use the dashboard's current configuration to answer "if an RTO scenario incident occurs, can points be scored" as a proxy score, and note in the report
（基于配置推断）。
Incident perspective grade: A ≥ 8 Excellent ｜ 6 ≤ B < 8 Good ｜ 4 ≤ C < 6 Needs improvement ｜ D < 4 Unqualified
§4 Output report template
# 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
Tool collaboration
- Pull panels/screenshots: call
grafana-analyzerskill (action=list_panels/export_only）。 - Read dashboard JSON: use
Readtool to read locally exported JSON. - When alert rule queries are involved: can combine with Grafana API or have the user paste the alert configuration.
Output principles
- Each FAIL/WARN must provide evidence of a specific panel or area, avoiding vague conclusions.
- Each recommendation must be actionable and must land on concrete actions such as "add panel / change threshold / add variable / add alarm".
- Do not fabricate data; when information is missing, clearly mark "insufficient information" in the report and do not directly give a PASS.
§5 Key Product Line Good/Bad Case Pattern Library
Source: Chapter 3 Product Line Dashboard Review of "Key Product Line Monitoring Dashboards and Alarm Configuration Review". If a dashboard under review is found to match the following patterns, directly cite the corresponding "anti-pattern number" or "template number" to improve the persuasiveness and consistency of the review.
5.1 Exemplars (Good Cases, can be used as reference blueprints)
| Number | Product Line | Dashboard | Key Best Practices |
|---|---|---|---|
| G1 | VCI / VCI Business Global Observability | Business Global Observability Dashboard | Health metrics pinned to the top, abnormal metrics automatically highlighted in red; service metrics support drill-down navigation; integrates alarm/inspection/change events; diagnostic metrics organized into four layers: ingress traffic/business instances/core links/system components; provides TOP account filtering |
| G2 | VPC Control Plane | VPC API + xgw Data Plane Dual Dashboards | Clear visual separation of Health/Diagnostic; first screen includes BGP status/resource Quota/traffic anomalies/probing; TopN nodes + TopN account drill-down; second-level traffic; dependencies DB/Redis/ETCD all included |
| G3 | veDB（for MySQL） | veDB Dashboard | Control plane + data plane core metrics together serve as Health; grouped arrangement conforms to architectural layering; includes complete layering of instances/capacity/dependency components/infrastructure; supports customer ID filtering |
| G4 | RDS / MongoDB / Redis | Each SRE Dashboard | Covers "mass outage" incident scenarios through basic resource monitoring; provides an independent OpenAPI monitoring dashboard; supports customer ID filtering; reflects good layering |
| G5 | TOS (ToB Observability Diagnosis) | TOS-ToB Business Observability Diagnosis Dashboard | Multiple groups of metrics each serve as Health; each group of metrics internally contains multi-dimensional auxiliary diagnosis; covers read/write requests, valid request decline, and control plane requests |
| G6 | VKE User Resource Usage | User Resource Usage Dashboard | Customer-dimension capacity/resource metrics pinned to the top as Health; diagnosis expanded in three levels: node pool → key nodes → POD; rich incident presets and covered |
| G7 | NAS (General + Cache) | bytenas-for-user-tob | Configure dedicated panels for key customers to facilitate SVIP critical support |
| G8 | DAS / VPN | Each Product Dashboard | Include all metrics of strong and weak dependency components such as optical modules, dedicated lines, EIP, IPSec, and BGP in the diagnostic layer |
5.2 Anti-patterns (Bad Cases, marked with deduction when matched)
| Number | Anti-pattern | Typical Phenomenon | Matched Product Line (Example) | Associated Check Item |
|---|---|---|---|---|
| BP1 | Health/Diag not partitioned | The dashboard only has metric "groups" (MGR, database, JVM...), and it is impossible to see at a glance whether the business has a problem | Kafka, RabbitMQ, VKO, Translation Dashboard | B1 |
| BP2 | Incident presets missing or presets too narrow | The product line has no RTO/incident presets; or the presets are reduced to only "physical machine outage" | APIG、VCI、PostgreSQL、CEN、Kafka、RabbitMQ | B3 |
| BP3 | Dashboard does not cover incident presets | There are already RTO scenarios but the dashboard has no monitoring configured (such as Kafka physical machine outage) | Kafka, CR, some VKE scenarios | B3 |
| BP4 | Missing customer ID filtering | Cannot filter by account_id, making it impossible to quickly locate customer issues; no SVIP-exclusive dashboard | Kafka, RabbitMQ, ECS (partial), CLB | B8 |
| BP5 | Overview dashboard has no data/fails | Loading errors, large amounts of NoData, expired variables | vePFS operations side/client side, ECS shared cloud dashboard | A4 + data accuracy |
| BP6 | Missing control plane OpenAPI monitoring | Dashboard only shows the data plane or operations plane; control plane API VALET is missing | NAT, CLB, VKE, CR, APIG (partial) | B3 |
| BP7 | Missing monitoring of dependent components | Only own service metrics; upstream/downstream DB/Redis/ETCD/optical modules/dedicated lines, etc. are missing | CLB, translation dashboard, CDP, HBase | B6 |
| BP8 | Chaotic layering; does not reflect troubleshooting logic | Diag metrics are piled up randomly and cannot be viewed top-down | HBase, MongoDB (partial), CDP | B7 |
| BP9 | Filtering only by PSM dimension | No drill-down by operations dimensions such as region/AZ/cluster | CDP | B8 + A1 |
| BP10 | Explosion in the number of metrics; slow loading | Too many and too dense panels; opening multiple panels causes loading delays | veDB (known issue) | Experience item |
5.3 How to cite review recommendations
In the output report §V (Issue List) / §VI (Improvement Recommendations), it is recommended to explicitly cite:
- When an anti-pattern is hit:
命中反模式 BP3：事故预设未被大盘覆盖（参考 Kafka 案例） - When giving improvement recommendations:
参考样板 G2（VPC 管控面）的 Health/Diag 视觉分区方式 - When the product line itself lacks incident presets, first recommend completing the incident presets, then require dashboard coverage (the order must not be reversed).
5.4 List of high-frequency improvement actions (can be copied directly into the report)
Automatically recommend corresponding actions based on the anti-patterns hit:
- BP1 → Add a separate Row "Health Metrics" at the top of the dashboard, using Stat/Gauge panels with red thresholds; move the remaining metrics down to the "Diagnostic Metrics" Row.
- BP2/BP3 → Synchronize the product line RTO/incident preset list and check dashboard coverage item by item; when incident presets are missing, also add them to the unified fault level definition document.
- BP4 → Add
account_idtemplate variable; copy an exclusive dashboard for SVIP customers and prefill account_id. - BP5 → Govern no-data panels: delete/repair data sources; configure
no dataalerts for key Health trends. - BP6 → Add control plane OpenAPI VALET (QPS, success rate, P99) panels, referencing gateway logs or Action dimension metrics.
- BP7 → List strong/weak dependencies (DB, Cache, MQ, ETCD, dedicated lines, optical modules) and add diagnostic panels one by one.
- BP8 → Rearrange the Row order top-down according to "business→service→dependency→resource", and change Row titles to a hierarchical tree structure (refer to the VPC dashboard).
- BP9 → Add region / AZ / cluster dimension variables and rewrite the queries.
- BP10 → Split the dashboard: move less commonly used fine-grained panels to separate sub-dashboards and jump to them via links.