spring-cloud-sleuth: RabbitMQ Tracing Informations are missing
Describe the bug I want to use a sleuth with RabbitMQ messaging, but I can’t see the tracing informations. I generated a demo application with spring start, and add some minimal functionality, to produce a message to rabbitmq.
Sample Here are the dependencies
<properties>
<java.version>15</java.version>
<spring-cloud.version>2020.0.0</spring-cloud.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-amqp</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-stream</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-stream-binder-rabbit</artifactId>
</dependency>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
application.yml
spring:
# Cloud Stream
cloud:
stream:
rabbit.bindings:
ipnMessageSupplier-out-0:
producer:
autoBindDlq: true
bindingRoutingKey: simplepay
routingKeyExpression: '''simplepay'''
bindings:
ipnMessageSupplier-out-0:
destination: financial
content-type: application/json
producer.requiredGroups: simplepay.financial
function:
definition: ipnMessageSupplier
# RabbitMQ
rabbitmq:
host: 127.0.0.1
port: 5672
username: root
password: root
and the application java
@SpringBootApplication
public class DemoApplication {
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
@Bean
Supplier<String> ipnMessageSupplier() {
return () -> "DEMO";
}
}
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 15 (9 by maintainers)
@jmecsei I think having an async client that hides even the blocking queue and you just need to call send on would be the best but I’m not familiar with the reasoning behind the current solution. I’m going to ask around next week to see what can we do.