标签冲突时听谁的
抓取到的样本可能自带 job、instance 等标签，而抓取配置本身也会生成同名标签。honor_labels 决定冲突时保留哪一方的值：默认保留抓取配置的值并把原值改写成 exported_* 标签，开启后则保留目标自带的值。联邦与推送场景尤其需要注意这个开关。
基本信息
| 默认取值 | false，冲突标签改写为抓取配置的值 |
|---|---|
| 开启效果 | true，保留目标自带的标签值 |
| 冲突处理 | 被改写的一方进入 exported_ 前缀标签 |
| 相关开关 | honor_timestamps 独立控制时间戳，不要混用 |
两种行为
两种行为
# 默认 false：冲突标签改写为抓取配置的值
- job_name: federate
honor_labels: false
# true：保留目标自带的标签值
- job_name: federate
honor_labels: true
# 推送网关场景常开启，保留上游写入的真实来源标签使用建议
| 场景 | 建议取值 | 原因 |
|---|---|---|
| 联邦上级 | true | 保留真实实例标签，避免被上级 job 名覆盖 |
| Pushgateway | true | 保留推送方写入的来源标签 |
| 普通抓取 | false | 由抓取配置统一标识来源更可控 |
| 多集群汇聚 | true | 跨集群数据需要保留原始身份 |
排查要点
- 查询结果里标签成对出现（原标签与 exported_ 标签）说明发生了冲突改写
- 跨集群数据互相覆盖时，先确认上下级的 honor_labels 取值是否一致
- 告警路由依赖 job 标签时，开启前先确认改写后路由仍然匹配
联邦上级常用 honor_labels: true 保留下级实例的真实标签，否则所有数据都会被上级的 job 名覆盖，无法按实例区分。
honor_labels 与 honor_timestamps 是两个独立开关：前者影响标签，后者影响样本时间，改动任一都需要重新验证数据一致性。
上线检查
- 改动前后各取一次样本标签，确认 job 与 instance 的取值符合预期
- 核对告警规则的标签匹配条件，避免路由因标签变化全部失效
- 确认下游消费方（看板变量、记录规则）不依赖被改写的标签名
- 先在测试环境复现标签冲突，确认改写后的标签名与告警规则匹配再上生产