SpringBoot How to propagate context with trace-id in CommandLineRunner with spring boot 3 and micrometer?

After migration to spring boot 3 and micrometer tracing library. The tracing IDs aren't automatically appended to the logs anymore for Classes which implement the CommandLineRunner interface unlike for rest controllers.

Example code

@Component
@Slf4j
@RequiredArgsConstructor
public class JobRunner implements CommandLineRunner {

    private final petsJobExecutor petsJobExecutor;

    @TrackExecutionTime
    public void run(String... args) {
        log.info("Started the job");
        petsJobExecutor.updatePets();
        log.info("Finished the job");
    }
}

How can I enable automatic trace-id context propagation for CommandLineRunner implementations in sprint boot 3 with micrometer?

Comment From: wilkinsona

Is the trace ID missing from the two info log calls in the command line runner itself or from logging that's happening within updatePets()? If it's the latter, it's very hard to offer any specific guidance as we don't know what petsJobExecutor is or how it has been implemented. Perhaps this Micrometer Tracing documentation helps? If it does not and you'd like further assistance, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

Comment From: MarcelEdmundFranke

Is the trace ID missing from the two info log calls in the command line runner itself or from logging that's happening within updatePets()?

Both cases, it's missing from the two info log calls and withn the update pets.

Comment From: MarcelEdmundFranke

@wilkinsona petsJobExecutor is a service component and JobRunner is scheduler

@Service
@ToString
@RequiredArgsConstructor
public class petsJobExecutor {

Comment From: MarcelEdmundFranke

@wilkinsona Do you still need more source code?

Comment From: wilkinsona

Yes, please. Without knowing how you've configured JobRunner and its threading, it's impossible for us to tell what's supposed to be happening. @TrackExecutionTime is also unknown to us – it isn't part of Spring Boot or Micrometer – so there's no way for us to know if there should even be a trace ID available.

Comment From: wilkinsona

I see you've also posted about this on Gitter and Stack Overflow. Unfortunately, cross-posting like this wastes people's time as @bclozel and I have now duplicated effort. That's time that we could have spent helping you or someone else.

I'm going to close this in favor of the Gitter discussion. I've also commented on the Stack Overflow question to hopefully avoid wasting anyone's time there too. We can re-open this if it turns out that some changes in Boot are required.

Comment From: MarcelEdmundFranke

@wilkinsona solved it. Micrometer acts not like sleuth lib

Fix

@Component
@Slf4j
@RequiredArgsConstructor
@Profile("!test")
public class JobRunner implements CommandLineRunner {

    @Autowired
    private final Tracer tracer;

    @Autowired
    private final ObservationRegistry observationRegistry;

    @Autowired
    private final petsJobExecutor petsJobExecutor;

    @TrackExecutionTime
    public void run(String... args) {
        Observation.createNotStarted("pets-job", observationRegistry).observe(() -> {
            log.info("Started the job");
            petsJobExecutor.updatePets();
            log.info("Finished the job");
        });
    }
}

Comment From: MarcelEdmundFranke

@wilkinsona Thanks for you support! :)