build-grafana-dashboards
关于
This skill helps developers create production-ready Grafana dashboards with reusable panels, template variables, and annotations. It's ideal for visualizing metrics from Prometheus/Loki, building SRE operational dashboards, or establishing version-controlled dashboard provisioning. Key capabilities include migration from manual setups and creating executive SLO compliance reports.
快速安装
Claude Code
推荐npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/build-grafana-dashboards在 Claude Code 中复制并粘贴此命令以安装该技能
技能文档
name: build-grafana-dashboards description: > 创建生产级 Grafana 仪表板,包含可复用面板、模板变量、注解及版本控制部署的预置配置。 适用于为 Prometheus、Loki 等数据源创建可视化图表、为 SRE 团队构建运营仪表板、 从手动创建仪表板迁移到版本控制预置配置,或建立高管级别的 SLO 合规报告。 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: observability complexity: intermediate language: multi tags: grafana, dashboards, visualization, panels, provisioning locale: zh-CN source_locale: en source_commit: 6f65f316 translator: claude translation_date: "2026-03-17"
构建 Grafana 仪表板
设计和部署 Grafana 仪表板,遵循可维护性、可复用性和版本控制的最佳实践。
适用场景
- 为 Prometheus、Loki 或其他数据源指标创建可视化展示
- 为 SRE 团队和事件响应者构建运营仪表板
- 建立高管级别的 SLO 合规报告仪表板
- 从手动创建仪表板迁移到版本控制的预置配置
- 使用模板变量在团队间标准化仪表板布局
- 创建从高层概览到详细指标的下钻体验
输入
- 必需:数据源配置(Prometheus、Loki、Tempo 等)
- 必需:需要可视化的指标或日志及其查询模式
- 可选:用于多服务或多环境视图的模板变量
- 可选:用于迁移或修改的现有仪表板 JSON
- 可选:用于事件关联的注解查询(部署、事件)
步骤
参见 Extended Examples 获取完整配置文件和模板。
第 1 步:设计仪表板结构
在构建面板之前规划仪表板布局和组织。
创建仪表板规格文档:
# Service Overview Dashboard
## Purpose
Real-time operational view for on-call engineers monitoring the API service.
## Rows
1. High-Level Metrics (collapsed by default)
- Request rate, error rate, latency (RED metrics)
- Service uptime, instance count
2. Detailed Metrics (expanded by default)
- Per-endpoint latency breakdown
- Error rate by status code
- Database connection pool status
3. Resource Utilization
- CPU, memory, disk usage per instance
- Network I/O rates
4. Logs (collapsed by default)
- Recent errors from Loki
- Alert firing history
## Variables
- `environment`: production, staging, development
- `instance`: all instances or specific instance selection
- `interval`: aggregation window (5m, 15m, 1h)
## Annotations
- Deployment events from CI/CD system
- Alert firing/resolving events
关键设计原则:
- 最重要的指标在最前面:关键指标在顶部,详细信息在下方
- 一致的时间范围:在所有面板间同步时间
- 下钻路径:从高层链接到详细仪表板
- 响应式布局:使用在各种屏幕上都能工作的行和面板宽度
预期结果: 仪表板结构文档清晰,利益相关者对指标和布局优先级达成一致。
失败处理:
- 与最终用户(SRE、开发者)进行仪表板设计评审
- 参照行业标准(USE 方法、RED 方法、四个黄金信号)进行对标
- 审查团队中现有的仪表板以保持一致性
第 2 步:创建带模板变量的仪表板
使用可复用变量构建仪表板基础以实现过滤。
创建仪表板 JSON 结构(或使用 UI 创建后导出):
{
"dashboard": {
"title": "API Service Overview",
"uid": "api-service-overview",
"version": 1,
"timezone": "browser",
"editable": true,
"graphTooltip": 1,
"time": {
"from": "now-6h",
"to": "now"
},
"refresh": "30s",
"templating": {
"list": [
{
"name": "environment",
"type": "query",
"datasource": "Prometheus",
"query": "label_values(up{job=\"api-service\"}, environment)",
"multi": false,
"includeAll": false,
"refresh": 1,
"sort": 1,
"current": {
"selected": false,
"text": "production",
"value": "production"
}
},
{
"name": "instance",
"type": "query",
"datasource": "Prometheus",
"query": "label_values(up{job=\"api-service\",environment=\"$environment\"}, instance)",
"multi": true,
"includeAll": true,
"refresh": 1,
"allValue": ".*",
"current": {
"selected": true,
"text": "All",
"value": "$__all"
}
},
{
"name": "interval",
"type": "interval",
"options": [
{"text": "1m", "value": "1m"},
{"text": "5m", "value": "5m"},
{"text": "15m", "value": "15m"},
{"text": "1h", "value": "1h"}
],
"current": {
"text": "5m",
"value": "5m"
},
"auto": false
}
]
},
"annotations": {
"list": [
{
"name": "Deployments",
"datasource": "Prometheus",
"enable": true,
"expr": "changes(app_version{job=\"api-service\",environment=\"$environment\"}[5m]) > 0",
"step": "60s",
"iconColor": "rgba(0, 211, 255, 1)",
"tagKeys": "version"
}
]
}
}
}
变量类型和用例:
- 查询变量:来自数据源的动态列表(
label_values()、query_result()) - 间隔变量:查询的聚合窗口
- 自定义变量:非指标选项的静态列表
- 常量变量:面板间共享的值(数据源名称、阈值)
- 文本框变量:用于过滤的自由格式输入
预期结果: 变量从数据源正确填充,级联过滤器正常工作(环境过滤实例),默认选择适当。
失败处理:
- 在 Prometheus UI 中独立测试变量查询
- 检查循环依赖(变量 A 依赖 B,B 依赖 A)
- 验证多选变量
allValue字段中的正则表达式模式 - 检查变量刷新设置(仪表板加载时 vs 时间范围变更时)
第 3 步:构建可视化面板
为每个指标创建具有适当可视化类型的面板。
时间序列面板(请求速率):
{
"type": "timeseries",
"title": "Request Rate",
"gridPos": {"h": 8, "w": 12, "x": 0, "y": 0},
"targets": [
{
"expr": "sum(rate(http_requests_total{job=\"api-service\",environment=\"$environment\",instance=~\"$instance\"}[$interval])) by (method)",
"legendFormat": "{{method}}",
"refId": "A"
}
],
"fieldConfig": {
"defaults": {
"unit": "reqps",
"color": {
"mode": "palette-classic"
},
"custom": {
"drawStyle": "line",
"lineInterpolation": "smooth",
"fillOpacity": 10,
"spanNulls": true
},
"thresholds": {
"mode": "absolute",
"steps": [
{"value": null, "color": "green"},
{"value": 1000, "color": "yellow"},
{"value": 5000, "color": "red"}
]
}
}
},
"options": {
"tooltip": {
"mode": "multi",
"sort": "desc"
},
"legend": {
"displayMode": "table",
"placement": "right",
"calcs": ["mean", "max", "last"]
}
}
}
统计面板(错误率):
{
"type": "stat",
"title": "Error Rate",
"gridPos": {"h": 4, "w": 6, "x": 12, "y": 0},
"targets": [
{
# ... (see EXAMPLES.md for complete configuration)
热力图面板(延迟分布):
{
"type": "heatmap",
"title": "Request Duration Heatmap",
"gridPos": {"h": 8, "w": 12, "x": 0, "y": 8},
"targets": [
{
# ... (see EXAMPLES.md for complete configuration)
面板选择指南:
- 时间序列:随时间变化的趋势(速率、计数、持续时间)
- 统计:带阈值着色的单个当前值
- 仪表盘:百分比值(CPU、内存、磁盘使用率)
- 条形仪表:在某个时间点比较多个值
- 热力图:值随时间的分布(延迟百分位数)
- 表格:多个指标的详细分解
- 日志:来自 Loki 的带过滤功能的原始日志行
预期结果: 面板正确渲染数据,可视化匹配预期指标类型,图例描述清晰,阈值突出显示问题。
失败处理:
- 在 Explore 视图中使用相同时间范围和变量测试查询
- 检查指标名称拼写错误或不正确的标签过滤器
- 验证聚合函数是否匹配指标类型(计数器用 rate,仪表用 avg)
- 检查单位配置(字节、秒、每秒请求数)
- 启用"Show query inspector"调试空结果
第 4 步:配置行和布局
将面板组织到可折叠的行中以实现逻辑分组。
{
"panels": [
{
"type": "row",
"title": "High-Level Metrics",
"collapsed": false,
# ... (see EXAMPLES.md for complete configuration)
布局最佳实践:
- 网格宽度为 24 个单位,每个面板指定
w(宽度)和h(高度) - 使用行分组相关面板,默认折叠不太关键的部分
- 将最关键的指标放在首个可见区域(y=0-8)
- 在行内保持一致的面板高度(通常为 4、8 或 12 个单位)
- 时间序列使用全宽(24),比较使用半宽(12)
预期结果: 仪表板布局逻辑有序,行正确折叠/展开,面板视觉对齐无间隙。
失败处理:
- 验证 gridPos 坐标不重叠
- 检查行面板数组是否包含面板(非 null)
- 验证 y 坐标在页面下方逻辑递增
- 使用 Grafana UI 的"Edit JSON"检查网格位置
第 5 步:添加链接和下钻
在相关仪表板之间创建导航路径。
仪表板级别链接的 JSON:
{
"links": [
{
"title": "Service Details",
"type": "link",
"icon": "external link",
# ... (see EXAMPLES.md for complete configuration)
面板级别数据链接:
{
"fieldConfig": {
"defaults": {
"links": [
{
"title": "View Logs for ${__field.labels.instance}",
# ... (see EXAMPLES.md for complete configuration)
链接变量:
$service、$environment:仪表板模板变量${__field.labels.instance}:来自点击数据点的标签值${__from}、${__to}:当前仪表板时间范围$__url_time_range:URL 编码的时间范围
预期结果: 点击面板元素或仪表板链接导航到相关视图,上下文保持不变(时间范围、变量)。
失败处理:
- URL 编码查询参数中的特殊字符
- 使用各种变量选择(全部 vs 特定值)测试链接
- 验证目标仪表板 UID 存在且可访问
- 检查
includeVars和keepTime标志是否按预期工作
第 6 步:设置仪表板预置配置
将仪表板作为代码进行版本控制以实现可重现的部署。
创建预置配置目录结构:
mkdir -p /etc/grafana/provisioning/{dashboards,datasources}
数据源预置配置(/etc/grafana/provisioning/datasources/prometheus.yml):
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
access: proxy
# ... (see EXAMPLES.md for complete configuration)
仪表板预置配置(/etc/grafana/provisioning/dashboards/default.yml):
apiVersion: 1
providers:
- name: 'default'
orgId: 1
folder: 'Services'
type: file
disableDeletion: false
updateIntervalSeconds: 30
allowUiUpdates: true
options:
path: /var/lib/grafana/dashboards
foldersFromFilesStructure: true
在 /var/lib/grafana/dashboards/ 中存储仪表板 JSON 文件:
/var/lib/grafana/dashboards/
├── api-service/
│ ├── overview.json
│ └── details.json
├── database/
│ └── postgres.json
└── infrastructure/
├── nodes.json
└── kubernetes.json
使用 Docker Compose:
version: '3.8'
services:
grafana:
image: grafana/grafana:10.2.0
ports:
- "3000:3000"
volumes:
- ./grafana/provisioning:/etc/grafana/provisioning
- ./grafana/dashboards:/var/lib/grafana/dashboards
environment:
- GF_SECURITY_ADMIN_PASSWORD=admin
- GF_USERS_ALLOW_SIGN_UP=false
- GF_AUTH_ANONYMOUS_ENABLED=true
- GF_AUTH_ANONYMOUS_ORG_ROLE=Viewer
预期结果: 仪表板在 Grafana 启动时自动加载,JSON 文件的更改在更新间隔后反映出来,版本控制跟踪仪表板更改。
失败处理:
- 检查 Grafana 日志:
docker logs grafana | grep -i provisioning - 验证 JSON 语法:
python -m json.tool dashboard.json - 确保文件权限允许 Grafana 读取:
chmod 644 *.json - 使用
allowUiUpdates: false测试以防止 UI 修改 - 验证预置配置:
curl http://localhost:3000/api/admin/provisioning/dashboards/reload -X POST -H "Authorization: Bearer $GRAFANA_API_KEY"
验证清单
- 仪表板在 Grafana UI 中加载无错误
- 所有模板变量以预期值填充
- 变量级联正常工作(选择环境过滤实例)
- 面板在配置的时间范围内显示数据
- 面板查询正确使用变量(无硬编码值)
- 阈值适当地突出显示问题状态
- 图例格式描述清晰且不杂乱
- 注解在相关事件时出现
- 链接导航到正确的仪表板并保持上下文
- 仪表板从 JSON 文件预置配置(版本控制)
- 响应式布局在不同屏幕尺寸上工作
- 工具提示和悬停交互提供有用的上下文
常见问题
- 变量未更新面板:确保查询使用
$variable语法而非硬编码值。检查变量刷新设置 - 查询正确但面板为空:验证时间范围包含数据点。检查抓取间隔与聚合窗口的关系(5m 的 rate 需要 >5m 的数据)
- 图例过于冗长:使用
legendFormat仅显示相关标签,而非完整指标名称。示例:用{{method}} - {{status}}代替默认值 - 时间范围不一致:设置仪表板时间同步以使所有面板共享相同的时间窗口。使用"Sync cursor"进行关联调查
- 性能问题:避免查询返回高基数序列(>1000)。使用记录规则或预聚合。限制昂贵查询的时间范围
- 仪表板漂移:没有预置配置时,手动 UI 更改会造成版本控制冲突。在生产环境中使用
allowUiUpdates: false - 缺少数据链接:数据链接需要精确的标签名称。谨慎使用
${__field.labels.labelname},验证标签是否存在于查询结果中 - 注解过载:过多的注解会使视图杂乱。按重要性过滤注解或使用独立的注解轨道
相关技能
setup-prometheus-monitoring— 配置为 Grafana 仪表板提供数据的 Prometheus 数据源configure-log-aggregation— 设置 Loki 用于日志面板查询和基于日志的注解define-slo-sli-sla— 使用 Grafana 统计面板和仪表面板可视化 SLO 合规性和错误预算instrument-distributed-tracing— 添加从指标面板到 Tempo 追踪视图的追踪 ID 链接
GitHub 仓库
相关推荐技能
content-collections
元Content Collections 是一个 TypeScript 优先的构建工具,可将本地 Markdown/MDX 文件转换为类型安全的数据集合。它专为构建博客、文档站和内容密集型 Vite+React 应用而设计,提供基于 Zod 的自动模式验证。该工具涵盖从 Vite 插件配置、MDX 编译到生产环境部署的完整工作流。
polymarket
元这个Claude Skill为开发者提供完整的Polymarket预测市场开发支持,涵盖API调用、交易执行和市场数据分析。关键特性包括实时WebSocket数据流,可监控实时交易、订单和市场动态。开发者可用它构建预测市场应用、实施交易策略并集成实时市场预测功能。
creating-opencode-plugins
元该Skill帮助开发者创建OpenCode插件,用于接入命令、文件、LSP等25+种事件。它提供了插件结构、事件API规范和JavaScript/TypeScript实现模式,适合需要拦截操作、扩展功能或自定义事件处理的场景。开发者可通过它快速构建响应式模块来增强OpenCode AI助手的能力。
sglang
元SGLang是一个专为LLM设计的高性能推理框架,特别适用于需要结构化输出的场景。它通过RadixAttention前缀缓存技术,在处理JSON、正则表达式、工具调用等具有重复前缀的复杂工作流时,能实现极速生成。如果你正在构建智能体或多轮对话系统,并追求远超vLLM的推理性能,SGLang是理想选择。
