给网关请求量补团队标签时出现many-to-many，怎样检查元数据唯一性

group_left只声明多对一匹配，并不会替你消除右侧重复元数据。先确认匹配键在元数据一侧唯一，再补团队标签；盲目max或随意挑一条会掩盖身份冲突。

列出左右向量和匹配键

请求指标按instance输出，元数据却对同一个instance分别标成团队A和B，查询无法决定应该给请求乘上哪一条。即使两条info值都等于1，标签身份仍不同。应先用count by(instance)检查一侧是否大于1，再追溯服务发现、重复注册和旧实例残留。

复现one侧重复导致失败

附件先交给promtool执行含重复元数据的表达式，要求出现many-to-many错误；随后将第二团队绑定到独立instance，关联得到one团队A的5与two团队B的7。失败记录和成功结果都保留，避免把“查询没返回”误判为零请求或权限不足。

元数据重复诊断可先执行count by(instance)(demo_info)>1，把唯一性问题独立于乘法表达式检查。若一个实例合法属于多个团队，关系本身就是一对多，此时应重新定义报表归属，不应强迫group_left从中随便选一个。数据模型明确以后再选择匹配键，查询才有确定含义。

核心表达式（完整建表与输入见附件）：

count by(instance)(demo_info) > 1

说明不能随意max掉真实归属冲突

去重键应覆盖实际身份边界。如果不同集群会复用instance，就应把cluster等稳定字段纳入on条件，而不是只在结果里显示。不要为了使表达式通过而丢掉团队字段；这可能让看板数值可用，却把告警或成本归属分到错误团队。

适用范围：全部伪造instance与team；不使用实验性info或fill功能，不修改真实监控标签。

配套样本与复核入口

• run.py：独立运行程序，包含合成输入、操作和正反例断言。
• case.json：输入说明、预期任务与适用范围，便于保存和交接。
• observed.json：本次实际执行输出；临时路径、进程号和计时可能随运行变化。

附件的第一次PromQL求值失败是预期部分，程序要求错误包含many-to-many，随后才执行修正后的成功测试。若第一次竟然通过，程序整体会失败，提醒输入重复条件被意外改掉。joined_values的5和7应分别归到两个团队，不能只核对总数12，因为错误合并团队也可能碰巧保持总和。

Python3.8以上与官方Prometheus3.5.0中的promtool。将工具加入PATH，或把PROMTOOL设为它的绝对路径。程序会在临时目录生成真实规则与测试输入，再调用promtool test rules；断言不符时退出失败，不用自造PromQL求值器替代。

python -B run.py

阅读输出时，先按case.json中的任务逐项核对网关PromQL group_left多对多，再与observed.json比较。非零退出表示依赖或断言需要处理，应保留实际错误。

一手依据1（on/ignoring及group_left限定向量匹配；one侧须使结果唯一。）；一手依据2（promtool规则测试支持输入序列、求值时刻、预期告警和表达式值，_与stale分别表示缺样与陈旧。）。

继续阅读：网关副本清单更新到一半监控会丢目标吗，怎样原子发布file_sd文件；网关监控图突然归零，是没有请求还是抓取已经断了；网关可观测性怎么做：比错误率更早报警的三个信号。