Grafana仪表盘

十个 Grafana 仪表盘 — SLO 燃烧、用户旅程、饱和度、队列、数据库 (DB)、缓存、内容分发网络 (CDN)、发布防护栏，以及一个待命“指挥室” — 助你及早发现事故。

说实话：凌晨两点，一千张图表也救不了你。真正能救你的是这十张正确的图表，它们基于第一性原理构建，并经过调优以凸显信号而非噪音。下面是我屡次看到能将“神秘故障”转化为“轻微波动”的仪表盘。每张图表都包含其工作原理以及你可以立即调整使用的代码片段。

假设：指标使用 Prometheus/PromQL，日志使用 Loki，追踪使用 Tempo/OpenTelemetry (OTel)。根据你的技术栈进行替换；这些模式仍然适用。

01 SLO 脉冲：错误预算燃烧（金丝雀中的金丝雀）

它告诉你什么： 你的错误预算现在是否正在燃烧？

面板： 4小时和30天燃烧率、燃烧倍数、滚动成功率、故障最多的端点。

PromQL (多窗口多燃烧):

# 99.9% SLOratio_5m  = sum(rate(http_request_duration_seconds_count{status!~"5.."}[5m]))           / sum(rate(http_request_duration_seconds_count[5m]))ratio_1h  = sum(rate(http_request_duration_seconds_count{status!~"5.."}[1h]))           / sum(rate(http_request_duration_seconds_count[1h]))burn      = ((1 - ratio_5m) / (1 - 0.999)) + ((1 - ratio_1h) / (1 - 0.999))

工作原理： 燃烧率使警报与客户痛点而非虚假的 CPU 峰值保持一致。

02用户旅程漏斗：转换在哪里下降了？

它告诉你什么： “搜索 → 产品 → 结账 → 支付”中的哪个步骤正在中断 — 接近实时。

面板： 步骤转换百分比、与上周的差异、P95 步骤延迟、按区域划分的掉线热图。

PromQL:

# Per-step success ratiossum(rate(app_event_total{event="checkout_success"}[5m]))/ ignoring(event) group_leftsum(rate(app_event_total{event="checkout_start"}[5m]))

工作原理： 在 Twitter 发现之前很久，你就能捕获到损坏的按钮、第三方故障或功能标志。

03针对基础设施的 USE 仪表盘（利用率、饱和度、错误）

它告诉你什么： CPU/内存/I/O 压力以及实际饱和度（队列、限制）。

面板： 节点 CPU 利用率、运行队列长度、磁盘利用率百分比、磁盘等待时间、网络丢包、受限容器。

PromQL:

# CPU saturation (runnable tasks)node_load1 / count(count(node_cpu_seconds_total{mode="idle"}) by (instance))# Disk saturationrate(node_disk_io_time_seconds_total[5m])

工作原理： USE 方法暴露剩余容量 (headroom)。你会看到瓶颈的到来，而不仅仅是当指针达到 100% 时。

04队列和反压：“我们能跟上吗？”面板

它告诉你什么： Kafka/Rabbit/SQS 的延迟和吞吐量；消费者健康状况。

面板： 每个消费者组的延迟、生产与消费速率、死信数量、最老消息时长。

PromQL:

# Kafka consumer lag (exporter varies)max(kafka_consumergroup_lag{group="payments"}) by (topic, partition)# Oldest message age (seconds)max_over_time(kafka_topic_oldest_message_age_seconds[5m])

工作原理： 慢速消费者往往是下游问题最早的症状。

05数据库实况检查：连接、锁和慢查询

它告诉你什么： Postgres/MySQL 在实际负载下是否健康？

面板： 活动连接数与最大连接数、锁等待次数和时长、按动词分类的 P95 查询时间、慢查询 Top-N (Loki)、复制延迟。

PromQL (Postgres):

# Waiting lockssum(pg_locks_count{mode!="AccessShareLock",state="waiting"})# Replication lag secondsmax(pg_stat_replication_lag_seconds)

Loki（慢查询表）：

{app="postgres"} |= "duration:" | json | duration > 200ms| stats count() by query

工作原理： 数据库可以优雅地失败——直到它们不再优雅。在应用程序崩溃之前，锁等待会飙升。

06缓存测谎仪：带上下文的命中率

它能告诉你什么： 你是否不必要地支付了主存储（main-store）成本？

面板： 随时间变化的命中/未命中率，未命中原因（冷缓存（cold）与被驱逐（evicted）），p95 缓存延迟，被逐出字节数（bytes ejected）。

PromQL (Redis/Dragonfly)：

sum(rate(redis_keyspace_hits_total[5m]))/ (sum(rate(redis_keyspace_hits_total[5m])) + sum(rate(redis_keyspace_misses_total[5m])))

工作原理： 命中率的悄然下降是你将获得的最低成本的早期预警。

07CDN/边缘早期预警：延迟、TLS 和源站错误

它能告诉你什么： 是不是互联网出了问题？

面板： 按接入点（POP）划分的 p90/p99 边缘延迟，TLS 握手时间，源站 5xx 错误率，缓存状态（HIT/MISS/BYPASS）。

LogQL（结构化边缘日志）：

{source="edge"} | json | status >= 500| stats sum(count) by pop, route

工作原理： 你将快速区分源站问题和某个不佳的接入点（POP）或互联网服务提供商（ISP）问题——从而减少徒劳的追查。

08发布安全栏：特性开关和每批次（cohort）错误增量

它能告诉你什么： 新功能是否对某个特定批次（cohort）造成了影响？

面板：`flag=on` 与 `off` 的错误率增量，p95 延迟增量，受影响的主要端点，自动化回滚提示。

PromQL（批次比较）：

err_on  = sum(rate(http_requests_total{status=~"5..",flag="on"}[5m]))/ sum(rate(http_requests_total{flag="on"}[5m]))err_off = sum(rate(http_requests_total{status=~"5..",flag="off"}[5m]))delta   = err_on - err_off

工作原理： 你得到的是因果提示，而不仅仅是相关性。非常适合渐进式交付（progressive delivery）。

09链路追踪拓扑迷你图：时间究竟花在哪里了？

它能告诉你什么： 哪个服务/端点导致了最新的延迟飙升。

面板： 服务依赖图（Tempo/OTel），按操作划分的 p95 链路段（span）持续时间，错误热点，“红色节点”自动聚焦。

Grafana 转换： 使用服务图（Service Graph）面板（Tempo）和列出 `service.operation`、`p95`、`error_rate` 的表格。

工作原理： 链路追踪消除了相互指责。问题节点会发出红光；你只需呼叫正确的团队。

10随叫随到指挥室：一览无余，一键直达

它能告诉你什么： “我们还好吗？”如果不好，首先看哪里。

布局：

第 1 行： 服务水平目标（SLO）燃尽图，活动告警（小表格），值班联系人。

第 2 行： p95 延迟 + 错误率（全局），请求量，饱和度（CPU/队列）。

第 3 行： “最近 5 次部署”（注解），按端点划分的错误，主要慢查询。

第 4 行： 运行手册（Runbook）链接和“静音噪声”开关（将时间切换到上周以获取上下文）。

ASCII 草图：

+------------------+----------------------+------------------+|  SLO Burn Gauge  |   Active Alerts      |  On-call: @you   |+------------------+----------------------+------------------+| p95 Latency      | Error Rate           | Request Volume   |+------------------+----------------------+------------------+| CPU Saturation   | Queue Lag            | DB Lock Waits    |+------------------+----------------------+------------------+| Deploy Annotations | Endpoint Errors    | Slow Queries     |+--------------------+--------------------+------------------+| Runbooks | Feature Flags | Toggle: compare to last week      |+--------------------------------------------------------------+

工作原理： 在事件发生时，你不想四处导航。你想要一个驾驶舱。

11不会频繁打扰你的告警

为每个仪表盘配置一个预算感知型 (budget-aware) 告警：

SLO 燃尽 (SLO Burn)：在 2 倍燃尽（快速）和 1 倍燃尽（慢速）时触发，使用分组标签 (`{service, region}`)；快速告警持续 10 分钟，慢速告警持续 30 分钟。

队列 (Queues)：基于延迟斜率 (lag slope)而非绝对值进行告警：`deriv(lag[10m]) > 0` 和 `lag > threshold`。

数据库 (DB)：锁等待 (lock wait) 超过 20 秒并持续 3 分钟；复制延迟 (replication lag) 超过 60 秒。

内容分发网络 (CDN)：任意接入点 (POP) 的源站 5xx 错误率在 5 分钟内超过 1%。

Grafana Mimir/告警 JSON 示意 (sketch):

{  "title": "Fast burn (99.9% SLO)",  "condition": "B",  "data": [    {      "refId": "A",      "expr": "((1 - ratio_5m)/(1-0.999)) > 2",      "intervalMs": 60000    }  ],  "for": "10m",  "labels": {"severity":"page","team":"api"},  "annotations": {"runbook":"https://…/runbooks/slo-burn"}}

12带来复利效应的小习惯

时间偏移 (Time shifts) (`now-1w`) 应用于关键面板，以消除周内季节性波动。

来自持续集成/持续部署 (CI/CD) 的注释 (Annotations)（如部署、功能开关）能减少猜测。

单位一致性：显示毫秒 (ms) 而非秒，百分比 (%) 而非小数。

链接 (Linking)：每个面板都链接到一个更深入的钻取仪表盘或一个探索视图。

13结语

你不需要更多的图表——你需要更好的意图。从 SLO 心跳 (SLO pulse) 和值班会商室 (on-call situation room) 开始。在基本情况平稳后，再添加队列 (queues) 和数据库 (DB) 相关的监控。然后设置发布防护栏 (rollout guardrails)，以便尽早发现特定用户群的问题。做到这些，事故就不会再是突如其来的惊吓，而会变成可管理的故事。

上一条：Prometheus和Grafana结合使用

下一条：Grafana修复CVSS 10.0分高危漏洞：SCIM配置缺陷可致权限提升