面板类型就是问题的形状

一句话总结

选择类型不是个人喜好问题，判断标准是：问题问的是随时间的变化、当前的单个值，还是数值的分布。

为什么需要它

类型选错时，图虽然画出来了，却得不到答案，而且这一点很难被察觉——画面看起来正常，数字也正确，只是在真正需要时无法显示所需信息。错误查询会以空白画面暴露问题，错误类型却悄无声息。

问题的形式	类型	示例
随时间如何变化	timeseries	错误率、p95 延迟
当前时刻的单个值	stat	当前请求率、剩余 error budget
相对于固定上限已使用多少	gauge	磁盘使用率、连接池
数值如何分布	heatmap	响应时间分布
多个对象的排名	table · bar	各 handler 的错误数

各种类型在什么情况下会出错

**用 gauge 表示每秒请求数。**gauge 用于显示“处于 0 与最大值之间的哪个位置”。每秒请求数没有固定最大值，指针位于哪里都不表达任何意义；它还没有时间轴，因此也无法回答“从什么时候开始增长”。gauge 只能用于定义了上限的值。

**用一条折线表示分布。**一条平均响应时间曲线，可以完美隐藏“半数用户等待了 2 秒”这一事实。平均值会被少数极大值拉动，却不显示这些极大值曾经存在。要观察分布，应叠加多个分位数或使用 heatmap。

**状态 dashboard 里只有 stat。**仅凭“当前错误率 3%”这个数字，无法知道它正在上升还是下降。在 incident 中，这个差异至关重要。展示单个数字时，应在旁边同时放置带有时间轴的 panel。

分位数不是平均值

从 histogram 计算分位数时，le 标签是bucket 边界，因此必须保留 le，并汇总其余标签。

histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

遗漏 sum by (le) 会使各实例的 bucket 相互分离，导致数值混乱。反过来，先分别计算 p95 再求平均也同样错误——**分位数不能取平均。**十个实例的 p95 平均值并不等于整体 p95。应该合并的是 bucket，而不是计算后的结果。

常见误解

**“类型以后再改就行。”**实际上不会改。panel 一旦画好就会一直保留，而错误类型会悄悄让它失去用途。

**“饼图看起来漂亮。”**饼图没有时间轴，也很难凭肉眼比较扇区大小。对于同一组数据，table 或 bar 几乎总是更好。

实际工作中真正重要的事

**在 panel 标题中写明单位和时间范围。**不要只写“错误”，而应写成“5xx 比例（5 分钟 rate）”。接到呼叫的人可能第一次看到该 panel；除了标题之外，他无法知道 0.004 表示比例、次数、每秒还是每分钟。

还应把轴的单位告诉 Grafana（如 percentunit、seconds）。凌晨 3 点时，0.4% 比 0.004 更容易读懂，223ms 也比 0.223 更直观。