17.6.3 Dashboard设计原则与常用模板

Dashboard 设计应以“面向场景、突出关键、易读易用”为核心原则。首先明确目标受众（运维/开发/管理）与场景（容量趋势、故障排查、发布验证、业务可用性），围绕核心业务指标与SLO/SLA进行布局。布局遵循“从总体到细节”的信息层级：顶部展示全局健康与关键KPI，中部展示核心组件与依赖关系，底部提供明细与排障视图。统一时间范围与单位，避免同屏出现过多维度和混合粒度的图表。

原理草图：指标到可视化#

设计原则#

以指标体系为基础：以红/黄/绿阈值、SLO、错误预算为导航，减少“炫图”与无关指标。
层级清晰：总览—组件—实例的三层视图，支持快速下钻。
可读性优先：统一色彩与命名规范，避免同屏颜色冲突；图例简洁。
对比与趋势：优先使用时序趋势、同比/环比、分位数（P95/P99）与TopN。
可操作性：关键面板配套跳转链接与说明，便于定位日志/告警/Runbook。

常用面板模板与适用场景#

基础资源总览：CPU、内存、磁盘、网络、负载、进程数；用于主机与节点健康。
服务可用性总览：请求量、成功率、错误率、延迟（P50/P95/P99）；用于服务SLO。
组件性能模板：MySQL/Redis/Nginx/Kafka/ZK等通用关键指标组合，便于横向比较。
容量与增长趋势：磁盘/对象/Topic/索引容量、增长速率、预测线；用于扩容规划。
告警摘要面板：按严重级别与组件聚合，展示TopN告警与处理时长。
变更与发布影响：发布窗口内的错误率、延迟、资源波动对比视图。
业务链路视图：按依赖关系展示上游/下游，结合流量与错误传播路径。

统一规范建议#

命名规范：组件-指标-维度，如 kafka-requests-rate、nginx-5xx-rate。
单位规范：使用Grafana单位格式化（bytes、ms、percent、req/s）。
颜色规范：红=故障/高风险，黄=警告，绿=正常，蓝=趋势/参考。
图表规范：关键指标用时序折线，分布用柱状或饼图，容量趋势用面积图。
说明规范：每个面板提供指标含义、告警阈值与排障链接。

安装与模板导入示例#

以下以 Grafana 社区模板导入为例（需提前配置 Prometheus 数据源）：

# 1) 通过 API 导入 Dashboard（示例ID为1860: Node Exporter Full）
GRAFANA_URL="http://localhost:3000"
API_KEY="替换为你的APIKEY"

curl -s -H "Authorization: Bearer ${API_KEY}" \
  "${GRAFANA_URL}/api/gnet/dashboards/1860" | \
  jq '.json' > /tmp/node-exporter-full.json

# 2) 导入到本地 Grafana
curl -s -H "Authorization: Bearer ${API_KEY}" \
  -H "Content-Type: application/json" \
  -X POST "${GRAFANA_URL}/api/dashboards/db" \
  -d @- <<'EOF'
{
  "dashboard": $(cat /tmp/node-exporter-full.json),
  "overwrite": true,
  "inputs": [
    {
      "name": "DS_PROMETHEUS",
      "type": "datasource",
      "pluginId": "prometheus",
      "value": "Prometheus"
    }
  ]
}
EOF

预期效果：Grafana 中出现 “Node Exporter Full” 仪表盘，面板正常显示 CPU/内存/磁盘等指标曲线。

示例：面板查询与单位规范#

以 Nginx 5xx 错误率为例（假设指标为 nginx_http_requests_total）：

# 5xx 错误率
sum(rate(nginx_http_requests_total{status=~"5.."}[5m]))
/
sum(rate(nginx_http_requests_total[5m]))

面板设置建议：
- Unit：percent (0-100)
- Legend：{{instance}}
- Thresholds：70%（黄），90%（红）

示例：Dashboard 结构化布局（ASCII草图）#

+-------------------------------------------------------------+
| 全局KPI: 可用性 | 错误率 | P95延迟 | 关键容量利用率          |
+------------------------------+------------------------------+
| 核心组件A趋势（CPU/内存/延迟）| 核心组件B趋势（QPS/错误率） |
+------------------------------+------------------------------+
| 依赖链路：上游 -> 当前 -> 下游（流量/错误传播）            |
+-------------------------------------------------------------+
| 详细实例与排障视图：TopN、日志跳转、告警详情                |
+-------------------------------------------------------------+

排错清单（常见“面板无数据”）#

数据源不可用：检查 Grafana Data Source 连接
bash curl -s -H "Authorization: Bearer ${API_KEY}" \ "${GRAFANA_URL}/api/datasources" | jq '.[].name'
PromQL 标签不匹配：确认 label 名称（如 instance/job）
bash # 直接在 Prometheus 查询 curl -s "http://prometheus:9090/api/v1/label/__name__/values" | jq
时间范围过小：将时间范围调整为 Last 1h/6h，查看是否有历史数据。
单位与阈值异常：指标已为百分比时，避免再乘 100。
采集间隔不一致：面板分辨率过高导致稀疏，调整 Min interval。

练习与实践#

练习1：自定义主机总览
- 目标：创建包含 CPU 使用率、内存使用率、磁盘使用率的总览面板。
- 要求：统一单位（percent），每个面板设置阈值（80/90）。
- 验证：通过 PromQL rate(node_cpu_seconds_total[5m]) 等完成。
练习2：服务SLO仪表盘
- 目标：为 Nginx 添加成功率与 P95 延迟面板。
- 验证：在面板中添加注释链接到 Runbook（URL 自定义）。
练习3：模板复用与变量
- 目标：为同类服务增加 service 变量，实现单一模板多服务复用。
- 验证：切换变量时面板联动刷新。

通过“统一规范 + 模板复用 + 场景化组合”，确保Dashboard在告警联动、故障定位与容量规划中形成闭环。