使用的版本：v6.3.1 ， 测试v6.2也有类似问题
如下图所示，可以看到两条查询，设置的legend是不一样的， 但是最后展示出来都是一样的
这个问题从v6.2开始出现，应该是新引入的问题。
v6.3.1版本，前端展示legend异常
Viewed 81
5 Answers
v6.2.0 为了修复 Legend 冲突问题需要用到 refId 字段，这个字段从 v6 版本开始就会存在的。
这些没有 refId 的大盘是从哪里来的？夜莺里面创建的还是导入的
下个版本先修复下该问题
夜莺版本的升级比较快，我目前在生产环境上的用法是有了新版本时，只升级夜莺的程序本体（自己做的all in one容器镜像）
整个数据库保持和之前一样。为了保证大盘视图，告警规则的前后一致性。
从6.0开始，目前用到了6.2数据库没变过。
v6.3.0的截图，要去即时查询里查一下看看是不是原始数据就少，promql可以看一下这请求(/api/n9e/query-range-batch)的 playload
采集源用的是categraf，数据上是没问题的， 测试过程中，只替换n9e这个二进制文件，其他配置文件、数据源均保持不变。 对比v6.1和v6.2（或者v6.3）非常明显能看到，同一个机器的同一个时间的同一个视图，legend没有正确展示，展示的都是第一个查询（也就是A）的legend。 挺奇怪的，对比了md5，确认是和官网列出的gz包的md5一致。等晚上方便了，我在测试环境试试看看
我也遇到了，6.1.0版本的时候没发现问题，升级到6.2.0之后，自定义的legend都显示异常了。
这种默认的，我从来没有改动过的图表，显示也不正常了，全都显示成第一个legend。
目前检查了正常的图形和不正常的图形的json文件, 发现存在如下区别
测试方式: 将异常的大盘, 手动增加refId字段后, 即可恢复正常,去掉后就会再次显示异常
不正常显示的图形中, 没有refId字段. 估计是从v6.2新版本n9e中用到了这个字段?
20231017更新：出现问题的是一个古老的windows大盘，初步怀疑是早期beta版本时候导入的大盘。目前升级到v6.3.4版本后，问题解决（当然如果不想升级二进制版本， 也可以自己修改大盘json，手动加上refId字段来解决）