仪表盘设计

这一课你将能做到

1. 用 RED（Rate / Errors / Duration）为判题接口设计最小值班面板集，每个面板回答一个固定问题
2. 用 USE（Utilization / Saturation / Errors）检查 CPU、内存、磁盘、Kafka 队列等资源瓶颈
3. 规划 on-call 看板的分层结构：症状 → SLO → 依赖 → 资源，并留下 drill-down 路径和 runbook 链接

为什么要学

仪表盘若变成「图表墙」——50 个面板堆在一屏，值班时反而找不到「用户是否受伤」。典型翻车：新人收到告警，打开 Grafana 看到满屏绿色曲线，不知道先看哪个，5 分钟后才定位到 RED 面板，止血时间被白白浪费。

好的面板回答固定问题：用户是否痛？痛多久了？可能在哪一层？预算还剩多少？ 本课讲设计原则；Grafana 变量、模板、点击操作见 prom-grafana。本课刻意不克隆那门课的操作步骤，而补齐 观测心智与布局。面试里「RED 和 USE 的区别」「怎么设计一个值班看板」是高频题。

先建立图像

方法	适用	三要素	判题系统示例
RED	请求驱动服务	Rate（速率）、Errors（错误率）、Duration（延迟分布）	提交接口 QPS、5xx 率、P99 延迟
USE	节点/容器/队列等资源	Utilization（利用率）、Saturation（饱和度）、Errors（资源错误）	Pod CPU%、Kafka consumer lag、磁盘 IO 错误

判题 backend 建议的 Grafana 行布局（从上到下）：

Row 1  RED   — 提交接口 RPS、5xx%、P50/P99（http_server_requests）
              用户是否痛？痛多严重？
Row 2  SLO   — 30 天可用率、剩余错误预算、burn rate 趋势
              承诺还剩多少余量？
Row 3  依赖  — MySQL 连接池、Kafka consumer lag、Redis 命中率
              下游是不是瓶颈？
Row 4  JVM   — 堆内存、GC 暂停、线程数（解释用，不替代 RED）
              应用内部有没有异常？
Row 5  USE   — 容器 CPU/内存/磁盘、网络吞吐（容量线索）
              资源是不是快满了？

跟着做

步骤 1：为判题接口画 RED 三格（最小值班面板）

纸上三格，每格一个 PromQL：

格 1：Rate（QPS）
  sum(rate(http_server_requests_seconds_count{uri="/api/judge/submissions"}[5m]))
  回答：现在多少人在提交？

格 2：Errors（5xx 率）
  sum(rate(http_server_requests_seconds_count{uri="/api/judge/submissions",status=~"5.."}[5m]))
  /
  sum(rate(http_server_requests_seconds_count{uri="/api/judge/submissions"}[5m]))
  回答：用户在报错吗？错误率多少？

格 3：Duration（P99 延迟）
  histogram_quantile(0.99,
    sum(rate(http_server_requests_seconds_bucket{uri="/api/judge/submissions"}[5m])) by (le))
  回答：最慢的 1% 用户等了多久？

应得到：任何新服务上线前的「最小可值班面板」——三格足够判断「用户是否受伤」。

步骤 2：为判题 worker 补 USE 检查清单

对某个 worker Pod：

Utilization：
  - CPU 使用率：container_cpu_usage_seconds_total
  - 内存使用率：container_memory_working_set_bytes / limit

Saturation：
  - Kafka consumer lag：kafka_consumer_fetch_manager_records_lag
  - 线程池队列深度：executor_queued_tasks

Errors：
  - 磁盘 IO 错误：node_disk_io_errors_total
  - 网卡丢包：node_network_receive_errs_total