RabbitMQ 队列有消息，Zipkin 查不到链路，先看消费者是否存在。生产者能写入队列，只证明发送链路的一部分，不能证明 Zipkin collector 已连接、消息格式可解析或存储查询正常。

从 HTTP 改成 RabbitMQ 后发生了什么

2019 年项目最初通过 HTTP 上报正常。改为 RabbitMQ 后，没有看到预期 zipkin 队列；手动建队列后客户端能写入，Server 却没有接收。管理界面显示消费者为零，重启 Zipkin 后才开始消费。

旧稿先怀疑手动建队列，后来把结果解释为服务端启动时加载配置。这个过程支持检查 collector 是否启动，但不能仅因重启有效就证明具体是哪一个配置或连接状态出错。

服务端与客户端分别配置

更早的接入记录使用独立 zipkin-server-2.15.0-exec.jar，而不是继续把 Server 嵌入自己的 Boot 应用。

以 Zipkin 2.15.0 为历史对照，RabbitMQ collector 在设置 addresses 或 uri 时启用；默认 HTTP 接收能力与 RabbitMQ 不是同一个开关。该版本 Server 文档

旧记录的启动形状为：

java -jar zipkin-server-2.15.0-exec.jar --zipkin.collector.rabbitmq.addresses=localhost:5672

执行它会启动服务并尝试连接，不是当前网站的启动命令。账号和密码应通过受控配置提供，不写进公开命令、源码或日志；不要为复用示例而使用默认凭据。

该历史 collector 还涉及 queue、virtual-host、concurrency、connection-timeout 以及 URI 等配置。URI 与离散连接参数的优先级需要按该版本核对，不能同时填两套却只观察其中一套。

客户端选择 rabbit sender

旧整合稿记录了 Spring Cloud Greenwich.SR1，客户端使用 spring-cloud-starter-zipkin 与 spring-rabbit。应由匹配的依赖管理固定版本，不使用 RELEASE 这样的浮动版本。

对应旧 Sleuth 2.x 线路，可关注以下配置关系：

spring:
  application:
    name: trace-demo
  zipkin:
    sender:
      type: rabbit
  sleuth:
    sampler:
      probability: 1.0
  rabbitmq:
    host: localhost
    port: 5672

账号、密码和虚拟主机由环境补齐。这里 probability 是该代配置中的采样概率，1.0 仅适合说明受控诊断；不能把原稿的 percentage 键当成所有版本通用，也不应默认让生产系统全量采样。版本和属性定义应对照Spring Cloud Sleuth 2.1.3 的属性源码。

用五段证据确认链路

  1. 客户端确实产生并发送符合协议的 span。
  2. 消息进入正确 broker、虚拟主机、交换路由与队列。
  3. 对应队列有有效消费者，确认是目标 Zipkin 实例。
  4. 消息被接收并解析，检查丢弃与存储错误。
  5. 在正确时间范围和服务条件下能查询到 trace。

队列存在只能覆盖其中一小部分。消费者为零时先看连接、权限、地址和 collector 启动日志；有消费者但仍查不到，则继续看消息格式、采样和存储。不要盲目删除队列或清空消息来制造“没有积压”的表象。

这与Armeria 启动异常是不同故障；进程没成功启动，与成功启动后没有消费者，应分别定位。