接入 Zipkin 时出现 Prometheus 报错，不代表故障一定在链路追踪服务。错误若明确说同名 meter 的标签键集合不同，先查指标注册入口，再单独处理链路采样。

标签键多了 exception，不是标签值不一样

2019 年整合 Spring Boot 与观测组件时遇到：

Prometheus requires that all meters with the same name
have the same set of tag keys.
existing keys: [method, status, uri]
new keys: [exception, method, status, uri]

冲突是同名指标分别使用三组和四组标签键，新增的是 exception。与 status=200 和 status=500 两种值并存不同，这里是指标形状不一致。

Micrometer 的 Prometheus 注册说明（1.14 参考） 讨论了同名 meter 的标签键限制。应统一同一语义指标的标签形状，不让成功路径省略异常键、失败路径才临时添加；具体空值约定按使用的框架处理。该文档用于解释限制，不代替 2019 年工程的精确版本。

关闭自动计时，是停了一条路径

当时用过这个历史属性：

management.metrics.web.server.auto-time-requests=false

它可让某条自动指标注册不再触发，因而避开冲突，也可能同时让请求耗时指标消失。这个改动只能作为定位线索，不能证明重复注册已被合理解决，更不能不看版本就用于当前 Spring Boot。

检查依赖树中 Boot、Micrometer 与注册器是否成套，再查自动 HTTP 埋点、自定义过滤器、重复导入和手动注册。找到两个入口后，决定保留统一的自动埋点，还是建立名字与语义都清楚的另一类指标。

不要把用户 ID、完整请求 URL、trace ID 加成标签来“区分”冲突，这会造成大量不同时间序列，并没有修复原指标的设计。

Sleuth 采样配置属于另一条线

同次整合还遇到旧的 spring.sleuth.sampler.percentage 不生效，当时按版本改为 spring.sleuth.sampler.probability。它们涉及链路采样，不是 Prometheus meter 标签注册。

历史采样行为可结合 Spring Cloud Sleuth 2.1 采样文档 阅读；不能把更名规则外推到所有版本或当前观测栈。

最后分别验收指标和链路

在隔离环境产生成功与失败请求，查看预期指标是否仍被暴露和采集、标签键是否一致；另查 trace 是否按配置产生并到达目标服务。启动不再报错，只验证了启动阶段，不能代替这两类运行结果。