Spring Cloud Openfeign Maintain the span from HTTP calls using feign clients with micrometer

Hi,

I am using spring boot 3.1.5. I migrated my code from sleuth to micrometer for tracing. I have it working logging traceId and spanId. But as somebody already asked here https://stackoverflow.com/questions/77044612/should-micrometer-generate-a-new-span-each-time-a-spring-boot-server-receives-a , I am trying to maintain the spanId when I call to other microservices through http using spring cloud open feign but it maintains only the traceId. I specify below the feign configuration I have:

@Configuration
public class FeignConfiguration {


    @Bean
    public Capability capability(final MeterRegistry registry) {
      return new MicrometerCapability(registry);
    }    

    @Bean
    public Logger.Level loggerLevel() {
        return Logger.Level.FULL;

    }
}

The logs enabled with loggerLevel method for feign clients are already logging with same traceId but different spanId. And of course when you call to other microservice, the spanId is different too. How to maintain the spanId in the feignClient and propagate it to other microservices as it worked with the old spring sleuth?. Thanks!!

Comment From: OlgaMaciaszek

@jonatan-ivanov, could you take a look at this issue?

Comment From: jonatan-ivanov

This issue somewhat seems like a duplicate of https://github.com/spring-cloud/spring-cloud-openfeign/issues/1014. Creating a new span for every single http request is the normal/default behavior since processing an http request is a separate operation that you usually want to observe. Please check Brave's joint spans feature and enable it like you did it in https://github.com/spring-cloud/spring-cloud-openfeign/issues/1014.

(Fyi, your StackOverflow link was broken, I fixed it.)

Comment From: spring-cloud-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-cloud-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.