Observability dashboard builder
Skill findscripter/everything-skills/02-engineering/observability-dashboard-builder
类书式 AI Agent 技能大典 · 精选/中文化/互见成网的 500+ 开源技能，可作为 Claude Code 插件市场一键安装。A curated, cross-referenced encyclopedia of 500+ open-source agent skills.
npx -y skills add findscripter/everything-skills --skill observability-dashboard-builderAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
当要把一堆指标变成运维人员真能照着排障的监控仪表盘（Grafana/SigNoz 等）时使用；做从「运维四问」出发的面板分组设计，产出含标题/单位/阈值/模板变量的可用 dashboard JSON 与质量清单；不适用于 SLO/告警体系设计或一次性临场排障。触发词：Grafana 仪表盘、SigNoz、监控面板
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.1 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it
何时使用
任务是构建一块运维人员能照着排障的监控仪表盘时使用。目标不是「把所有指标都显示出来」，而是回答四个运维问题：
- 它健康吗？（is it healthy）
- 瓶颈在哪？（where is the bottleneck）
- 什么发生了变化？（what changed）
- 谁该采取什么行动？（what action should someone take）
不该用的边界：
- 只是要设计 SLI/SLO、错误预算、多窗口燃尽率告警等可观测性体系 → 用
observability-strategy-designer。 - 一次性线上故障的临场排查（本技能产出的是可复用看板，不替代实时 oncall 操作）。
- 仅需安装/部署某个监控工具，不涉及面板设计。
步骤
1. 先定运维问题，再谈布局
围绕这几类组织面板，禁止从视觉布局起步：
- 健康 / 可用性（health / availability）
- 延迟 / 性能（latency / performance）
- 吞吐 / 流量（throughput / volume）
- 饱和 / 资源（saturation / resources）
- 服务特有风险（service-specific risk）
2. 研究目标平台的 schema
先检视已有 dashboard，再动手，重点看：JSON 结构、查询语言（Grafana=PromQL/LogQL，SigNoz=ClickHouse/PromQL）、模板变量（variables）、阈值着色样式、分区布局。
3. 构建「最小有用看板」
推荐分区结构：
- 概览（overview）
- 性能（performance）
- 资源（resources）
- 服务特有分区（service-specific）
4. 砍掉虚荣面板（vanity panels）
每个面板都要能回答一个真实问题；答不上来就删掉。
指令
护栏（Guardrails，硬约束）：
- 不要从视觉布局开始，要从运维问题开始。
- 不要因为某个指标「存在」就把所有可用指标都塞进去。
- 不要把健康、吞吐、资源面板无结构地混在一起。
- 不要交付没有标题、单位、合理阈值的面板。
质量清单（交付前逐项核对）：
- dashboard JSON 合法（可被 Grafana/SigNoz 导入）
- 分区分组清晰
- 每个面板都有标题与单位
- 阈值 / 状态色有意义（红=严重、琥珀=警告、绿=健康）
- 为常用筛选维度配置了模板变量（如 service、instance、env）
- 默认时间范围与刷新频率合理
- 没有「无运维价值」的虚荣面板
示例
Elasticsearch
- 集群健康（cluster health）
- 分片分配（shard allocation）
- 搜索延迟（search latency）
- 索引速率（indexing rate）
- JVM 堆内存 / GC
Kafka
- broker 数量
- under-replicated 分区数
- 进出消息速率（messages in / out）
- 消费者滞后（consumer lag）
- 磁盘与网络压力
API 网关 / Ingress
- 请求速率（request rate）
- p50 / p95 / p99 延迟
- 错误率（error rate）
- 上游健康（upstream health）
- 活跃连接数（active connections）
注意事项
- 「显示全部指标」是反模式：信息越多，运维时认知负荷越高、越难定位问题；宁缺毋滥。
- 同一屏内不要混排不同语义（健康 vs 资源），用分区把同类问题聚到一起。
- 阈值要可解释——颜色映射到「该不该有人动作」，而不是好看。
- 模板变量决定了一块看板能否复用到多服务 / 多环境，优先在采集标签里规划好维度。
- 先确认目标平台的查询语言与 JSON schema 再写面板，避免生成不可导入的配置。
互见
- requires：无强前置；建议先有指标采集（Prometheus 等）就位。
- related：
grafana-dashboards、prometheus-configuration、distributed-tracing—— 同域的采集与可视化邻居。 - combines_with：
observability-strategy-designer—— 先用它定 SLI/SLO 与告警体系，本技能把这些指标落成可运维看板；incident-commander-framework—— 故障时看板是 IC 的态势来源。
采编自 affaan-m/everything-claude-code（MIT 许可）。