1. 为什么双 Y 轴这件事值得单独写一篇监控大盘做久了你会发现一个很尴尬的现象CPU 使用率是 0.8 这种小数内存是 16GB 这种大数QPS 是 3000 这种千位数网络流量又是 120MB/s。这几条线要是全塞进一张图里那个 0.8 的曲线基本就是贴着 X 轴爬肉眼根本分辨不出来整张图看起来就像一条直线加一堆巨浪。我最早做 Grafana 面板的时候就吃过这个亏。当时给一个业务监控大盘做“综合概览”想着把请求量、响应时间、错误率画在一张图上省地方又直观。结果交上去之后运维同事看了一眼就问中间那条平的是什么东西我一看是响应时间因为请求量是几万响应时间是几百毫秒坐标轴一拉响应时间直接趴地上了。所以双 Y 轴这个东西看着是个很小的绘图设置实际上它解决的是一个非常具体的表达问题当多条曲线的数值量级差异很大时如何让它们在同一张图里都清晰可读。这篇就把 Grafana 双 Y 轴的完整玩法讲透包括它背后的坐标系逻辑、不同版本里的配置入口差异、和单位换算的关系、以及我踩过的那几个典型的坑。适合谁看已经用上 Grafana、能跑通基本查询、但是对面板表达效果不满意的人。如果你连数据源都还没接通建议先把 Prometheus 和 Grafana 跑起来再回来看这篇不然有些概念会比较抽象。2. 双 Y 轴到底在解决什么问题2.1 从一次“曲线挤成一条线”说起先还原一个真实场景。假设你有一台应用服务器你想在同一张图上观察三个指标CPU 使用率0 到 1 之间的小数、堆内存使用量单位 MB可能是几百到几千、以及每秒请求数单位 QPS可能是几千。如果这三个指标共用一个 Y 轴Grafana 会默认取整个数据集里的最大值作为上界。假设 QPS 峰值是 8000那 Y 轴刻度就是 0 到 8000。CPU 使用率的 0.6 在这个尺度下位置是 0.6/8000画出来基本和 X 轴重合。堆内存 2000 倒是能看见但它和 QPS 共享刻度你没法直观判断“内存涨了 500MB 算多还是算少”因为刻度被 QPS 拉大了。双 Y 轴的解法很直接给右边的曲线配一套独立的刻度。左边 Y 轴给 CPU 和内存用右边 Y 轴给 QPS 用。这样每条曲线都能用满整个绘图区域的高度涨跌趋势一目了然。注意双 Y 轴解决的是“可读性”问题不是“关联性”问题。它能让你看清两条曲线的形状是否同步但不能告诉你它们之间有因果关系。看到 CPU 曲线和 QPS 曲线同时上扬只能说明“疑似相关”要不要下结论还得看别的证据。2.2 左轴和右轴各自适合放什么这里有个经验性的分法我用了几年下来觉得比较稳把“你想重点观察变化趋势”的指标放到右轴把“作为背景参照”的指标放到左轴。举个例子做接口监控的时候请求量QPS通常波动很大是你要重点看的而系统负载可能变化平缓是背景。那就 QPS 放右轴负载放左轴。反过来如果你就是想看错误率有没有异常抬升那错误率放右轴请求量放左轴当背景。还有一种更机械但也好用的分法按单位分轴。百分比、小数、比率放一个轴绝对值字节、毫秒、个放另一个轴。因为 Grafana 的单位格式化是按轴走的同一根轴上如果混了两种单位鼠标悬停的时候 tooltip 显示会很别扭一会儿是 0.85一会儿是 3421读起来费劲。2.3 Grafana 里的“轴”到底是怎么组织的很多人第一次配双 Y 轴会困惑为什么我在 Overrides 里选了轴曲线还是不动这是因为它涉及到三层结构得理清楚。第一层是Panel 级别的默认配置也就是 Axes 那一栏。这里设置的是“默认情况下这条 Query 走哪个轴”。第二层是Query 级别的每个 Query 可以单独指定 Axis。第三层是Series Override在 Field 或者 Overrides 标签页里可以针对某条具体的序列覆盖轴设置。实际配的时候我一般这么走先在 Panel 的 Axes 设置里把默认轴定好然后在每个 Query 的选项里明确指定 Left 还是 Right。如果某个 Query 返回了多条序列需要在 Overrides 里逐条或者按正则匹配来指定。搞清楚这个层级关系后面遇到“改了没生效”就不会抓瞎。3. 手把手配置双 Y 轴从入门到能打3.1 不同 Grafana 版本的操作入口差异Grafana 的版本迭代挺快的面板编辑器前后改过好几轮这里必须先说清楚入口在哪不然很多人卡在第一步。在比较主流的版本区间里面板编辑器的右侧通常是 Query / Transform / Alert / Panel 这样的标签。老一些的版本里Panel 标签下有个 Axes 折叠区里面能直接看到 Left Y 和 Right Y 的配置还有一个“Show right Y axis”的开关。新版本的 Time series 面板里右侧 Y 轴变成了通过 Field 的 Axis 属性来控制也就是在 Overrides 里给字段设置“Axis placement”。我整理了一个对照表方便你对号入座面板类型 / 版本区间右轴开启方式单条序列指定轴的方式老版 Graph 面板Panel 标签下 Axes 里的 Right Y 配置项每个 Query 下方的 Axis 下拉框新版 Time series 面板Overrides 里设置 Axis placement 为 RightField 配置或 Series Override 中的 Axis使用 Transform 后的数据同上但要注意字段名匹配按字段名或正则匹配设置 Axis提示如果找不到右轴开关先确认你用的是 Graph 面板还是 Time series 面板。这两个面板的配置逻辑差别挺大网上很多老教程说的是 Graph 面板你照着在新面板里找自然会找不到。3.2 用 Override 精确控制每一条曲线Overrides 是 Grafana 里最好用也最容易翻车的功能之一。它的逻辑是你先定义一个匹配规则匹配到某个字段也就是某条曲线然后再给这个字段加属性。比如你有三条序列名字分别是cpu_usage、mem_used、qps。你想让qps走右轴。操作路径是在 Overrides 里新增一条规则匹配方式选“Fields with name”值填qps然后添加 Override 属性选“Axis placement”设置成 Right。这里有几个坑要说清楚字段名必须精确匹配。Prometheus 数据源在 Grafana 里的字段名通常是{__name__qps, instance...}这种形式或者被 Legend 格式化之后的名字。如果你的 Legend 格式设成了{{instance}} - {{__name__}}那字段名可能就变成10.0.0.1:9100 - qps你在 Override 里写qps是匹配不上的。正则匹配要慎用。匹配方式里有个“Fields with name matching regex”用好了很省事但正则写错会导致匹配到不该匹配的字段把左轴的曲线也挪到右轴去。Override 的执行顺序有时会影响结果。多个 Override 同时匹配一个字段时后定义的通常生效但不同属性之间不一定互相覆盖最好一个字段只写一条 Override。3.3 单位格式化双轴的“隐形配菜”双 Y 轴配好了很多人会忽略单位这件事。我见过不少大盘右轴显示的是0.0000001这种原始小数值看起来非常难受。单位配置的位置在 Panel 的 Axes 区域左右轴可以分别设置。常用的单位有percent (0-100)适合已经乘过 100 的百分比percentunit (0.0-1.0)适合 0.85 这种小数比率会自动显示成 85%bytes (SI)或bytes (IEC)内存、流量类指标ms或s时间类指标reqps每秒请求数专门给 QPS 用这里有个特别实用的技巧右轴用了reqps之后再配合 Grafana 的 “Decimals” 设置能把 3200 显示成 3.2K刻度也不会挤成一团。还有一个容易忽略的点percentunit和percent别混用。如果你的 PromQL 里已经用rate(x[5m])算出的是 0.72 这种小数那就用percentunit如果你自己乘了 100 得到 72那就用percent。用错了会显示成 7200% 这种离谱数字我见过不止一次。4. 几个典型场景的完整实操记录4.1 场景一QPS 与响应时间同图对比这是最常见的双轴需求。目标右轴显示 QPS左轴显示 P95 响应时间毫秒。数据源是 Prometheus两条查询大概长这样# Query AQPS sum(rate(http_requests_total[5m])) # Query BP95 响应时间 histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))在 Grafana 里Query A 的 Legend 我习惯写成QPSQuery B 写成P95 Latency。然后进 Overrides给 Legend 为QPS的那条设置 Axis placement 为 Right单位设为reqps。左轴保持默认单位设为ms。这里有个细节histogram_quantile算出来的是秒单位如果是s显示 0.234 这种值。我一般会在 PromQL 里直接乘 1000 转成毫秒或者用 Grafana 的 “Unit” 设成s让它在 tooltip 里自动格式化。两种都行看个人习惯但整个大盘最好统一不然排查问题时看着累。配完之后的效果是QPS 曲线在右轴满格波动延迟曲线在左轴有自己的尺度。当 QPS 冲高、延迟同时抬升的时候两张曲线的“同步感”一眼就能看出来。这就是双轴最大的价值。实操心得如果两条曲线的峰值出现时间总是错开几秒别急着下结论说“没关系”。Prometheus 的rate窗口和采集间隔会导致时间上的轻微偏移建议把时间范围拉到 6 小时以上看整体趋势而不是盯着 5 分钟的图。4.2 场景二内存使用量与 GC 次数做 JVM 监控的时候内存几百 MB 到几 GB和 GC 次数可能是个位数到几千量级差得远。这时候左轴放内存单位bytes右轴放 GC 次数单位。PromQL 示例# Query A堆内存使用 jvm_memory_used_bytes{areaheap} # Query BGC 速率 rate(jvm_gc_collection_seconds_count[5m])GC 次数用rate算出来是“每秒次数”本身就很小。这里我建议用increase(jvm_gc_collection_seconds_count[5m])来看“5 分钟内的增加量”数值会更直观单位设成short或者不设单位。这个场景里有个坑jvm_memory_used_bytes如果带多个areaheap、nonheap和多个id会返回一堆序列。你只想让 heap 走左轴就要用 Legend 或者 Override 精确匹配。我的做法是在 PromQL 里直接过滤掉比如加上{areaheap}从源头减少序列数量比在 Override 里做减法省心。4.3 场景三容器 CPU 与网络流量K8s 监控里某个 Pod 的 CPU 使用率0 到 1 的小数和网络接收流量每秒几十 KB 到几 MB放一起对比也是很典型的需求。# Query ACPU 使用率 sum(rate(container_cpu_usage_seconds_total{container!}[5m])) by (pod) # Query B网络接收速率 sum(rate(container_network_receive_bytes_total[5m])) by (pod)这里的问题在于两条 Query 都用了by (pod)所以每条都会返回多个 Pod 的序列。如果 Pod 有 20 个那就是 40 条曲线眼睛直接看花。我的处理方式是先用变量Variable做一个 Pod 选择器然后在 Query 里引用这个变量。比如定义一个$pod变量Query 改成container_cpu_usage_seconds_total{pod~$pod}。这样默认只显示选中的 Pod想看哪个选哪个图面上永远清爽。轴分配上CPU 是小数值走左轴单位percentunit网络流量走右轴单位bytes。这样两个轴的刻度差距不会太夸张都有合理的分辨率。注意container_network_receive_bytes_total算出来的原始值是字节级的大数用rate之后是每秒字节数单位设成bytes (SI)Grafana 会自动按 KB/MB/GB 来显示刻度比原始数字好看得多。5. 那些让人抓狂的问题和排查方法5.1 改了轴设置但曲线没动这大概是双轴配置里出现频率最高的问题。排查思路按这个顺序走第一步确认你改的是不是当前生效的那块配置。Grafana 的 Overrides 有时会有多条规则可能你改的那条被后面的规则覆盖了。把 Overrides 展开从下往上扫一遍看看有没有别的规则也匹配了同一个字段。第二步确认字段名匹配。把鼠标移到图例上看看 Grafana 显示的那条序列叫什么名字。如果 Legend 做过格式化或者用了 Transform 改了字段名那 Override 里的名字就必须和显示的完全一致。第三步确认 Query 级别有没有硬指定轴。有的老面板在 Query 选项里就设了 Axis它可能会压过 Override 的设置。把 Query 选项展开检查一下。第四步如果这个面板是从别的地方拷贝过来的比如从别的大盘导入的 JSON那可能里面残留了旧的数据源引用导致查询本身就没返回数据。这种情况下图是空的自然看不出轴的变化。渲染报错grafana failed to upgrade legacy queries datasource was not found就是典型的旧数据源 ID 对不上需要在面板设置里把 Data source 重新指一遍。5.2 鼠标悬停时 tooltip 显示混乱tooltip 是按轴的顺序显示的默认左轴的序列在前右轴在后。如果同一个轴上有多个序列它们的单位又不一样tooltip 里就会出现数字跳动的情况。解法有两个一是统一同轴序列的单位二是把 tooltip 模式从 “All series” 改成 “Single”只显示当前悬停的这条。我一般用后者排查具体某条曲线时更清爽。5.3 右轴的刻度线和左轴“打架”双轴图常见的一个视觉问题是左轴和右轴的网格线不对齐或者刻度数字挤在一起。这通常是因为两个轴的数值范围不同Grafana 自动计算的“nice number”步长不一致。处理办法在 Axes 设置里手动指定 Min 和 Max。比如左轴固定 0 到 1右轴固定 0 到 10000。但手动指定有风险如果数据超界曲线会被截断。我通常只在做“大屏展示”这种要求视觉稳定的场景才手动锁定范围日常排查用的面板就让它在自动模式下跑。还有一个技巧右轴的刻度标签可以设成不显示只在 tooltip 里体现。这在多轴图特别多的大盘上能减轻视觉负担让主次更分明。5.4 拷贝面板之后双轴配置丢失从别的大盘里“Copy panel”再粘贴到自己这边是常规操作。但这个过程中Overrides 里的字段匹配规则经常会失效因为字段名依赖具体的 Legend 格式和数据源。更麻烦的是如果目标 Grafana 里没有对应的数据源面板会直接报错连数据都出不来。稳妥的做法是拷贝面板时先把 Legend 格式确认一遍粘贴后第一时间检查数据源指向然后逐条验证 Override 是否还匹配得上。如果字段名变了重新选一次就行。常见现象大概率原因处理方式曲线全挤在底部量级差异大未分轴给大数值序列指定右轴改了 Axis 没反应Override 顺序或字段名不匹配检查 Override 顺序与 Legend 格式面板报 datasource was not found拷贝自其他环境数据源 ID 失效面板设置里重新指定数据源右轴刻度挤在一起未设单位或未限制小数位配置单位与 Decimalstooltip 数字乱跳同轴序列单位不统一统一单位或改 tooltip 模式6. 一些提升效率和稳定性的经验6.1 用变量和模板化减少面板数量一个实用的思路是与其给每个指标画一张图不如做一张图用变量控制显示哪些序列、哪个走右轴。Grafana 的 Variables 支持custom、query、interval等多种类型配合repeat功能还能自动生成多行面板。我见过一个很漂亮的做法定义变量left_metric和right_metric然后在 Query 里用$left_metric和$right_metric引用Axis 设置里也根据变量值来动态判断。不过 Axis 本身不太容易直接绑变量实际更常见的做法是固定两条 Query用变量控制它们的过滤条件。这个思路的好处很明显面板数量少了维护成本就低改一处单位设置所有复用的地方一起生效。6.2 从 Docker 环境快速搭一套练手环境想练双轴配置手边最好有一套能跑的环境。用 Docker Compose 起一套 Prometheus Grafana 是最省事的路径两个服务加一个数据卷几十行 YAML 就能拉起来。镜像用官方的最稳妥注意在docker-compose.yml里把 Grafana 的 3000 端口和 Prometheus 的 9090 端口映射出来再加一个GF_SECURITY_ADMIN_PASSWORD环境变量设定管理员密码。这里有个细节新手常踩Prometheus 的prometheus.yml挂载路径要对容器里默认读/etc/prometheus/prometheus.yml。如果你把配置挂到别的位置容器启动会用默认配置你抓的数据全都不对还以为是 Grafana 的问题。另外Grafana 启动后要手动添加数据源URL 填http://prometheus:9090用 Compose 的服务名不是 localhost。这一步填错的话面板会一直提示数据源错误也会间接影响你对轴配置的判断。6.3 告警配置和可视化的关系双轴图主要是给人看的但同一个指标也可以配告警。Grafana 的 Alerting 功能可以基于面板查询的表达式来设置阈值规则Prometheus 侧也有 Alertmanager 做告警路由。我的建议是可视化面板只管“看清趋势”告警规则尽量用独立的、阈值明确的 PromQL 表达。不要指望通过双轴图来判断“要不要报警”因为可视化里的单位、轴缩放、时间范围都是为阅读优化的不是为判断阈值设计的。如果同一个指标既要画图又要告警那就在 PromQL 里把它算成统一口径图的轴配置和告警的阈值都围绕这个口径来避免“图上看着是 80%告警却按 0.8 判”这种不一致。6.4 关于面板 JSON 的一点私货Grafana 的面板可以导出成 JSON这个老手都很熟。双轴配置在 JSON 里对应的字段通常在fieldConfig.overrides里找到matcher和properties那段能看到custom.axisPlacement设为right这样的结构。我个人的习惯是复杂面板先在界面上配好导出 JSON 存一份到 Git 里改坏了能快速回滚。如果要在多个环境之间同步大盘用 JSON 导入导出比手动点更可靠。但要注意 JSON 里的datasource字段跨环境导入时记得改成目标环境实际的 UID。还有一点导出 JSON 里可能带着id和version字段导入新环境时这两个值有时会引发冲突手工删掉再导入通常更顺。7. 最后分享几个我自己总结的小技巧先说一个最能提升观感的给右轴的曲线换一种线型和颜色。左轴用实线、右轴用虚线或者左轴用冷色、右轴用暖色。别小看这一步双轴图最容易让人读错的地方就是“看错颜色对错了轴”线型一区分误读率直线下降。第二个技巧是善用 “Draw as” 和 “Line width”。如果右轴的指标是离散事件比如每分钟的 GC 次数用 Bars 或 Points 显示左轴的连续指标用 Line这样两种数据的性质差异在视觉上就能分开轴归属也更清楚。第三个是关于时间范围的。双轴图在短时间窗口比如 5 分钟里看起来“同步”的两条曲线拉到 24 小时可能完全看不出相关性。我排查问题时的习惯是先看 6 小时再看 24 小时最后看 7 天不同时间尺度下结论经常不一样。第四个是别贪心。一张图最多两条轴再多就没法看了。如果你发现指标实在太多那就拆成两张图上面一张跟下面一张用同一个时间范围联动阅读体验比硬塞进一张图好得多。最后一条也是我觉得最重要的一条双轴图的每一个轴都要能一句话说清楚“它代表什么”。如果配完之后你自己都得看图例才想得起来右轴是什么指标那这张图就没配好。好的双轴图是一眼看左轴知道背景是什么一眼看右轴知道重点看什么中间两条线的走势关系是不需要思考就能感受到的。