spring-cloud-sleuthmicrometer

Spring Cloud Sleuth to Micrometer migration: options to close gaps


We currently use BaggageFields and Sleuth to propagate custom data elements through several integrations/use cases: REST calls, Kafka, and @Asynch cases.

Sleuth has served us well, and our preferred path is to transition from Sleuth to Micrometer, but in reading through Micrometer doc and after testing, it seems that Micrometer does not yet support Kafka for our use case.

We found this issue opened by Marcin Grzejszczak https://issues.apache.org/jira/browse/KAFKA-15191 Which proposes adding Micrometer instrumentation to kafka. Looks like there has not been any activity on it.

Given that we need to move forward with Spring Boot 3 migration of apps that need this functionality, we're exploring solution options to get by until the Micrometer approach offers the necessary support.

We're wondering if anyone can offer high level insights?

Idea #1: We're exploring the possibility of forking Sleuth code and eliminating pieces we don't need.

Questions that come to mind:

  1. What pieces of Sleuth would we need? We know for sure we can exclude code for the integrations that we don't need.

  2. It's documented that Sleuth is not compatible with Spring Boot 3. Specifically, what areas would need to be remediated?

Idea #2: start with Micrometer and pull in pieces from Sleuth to close the gap.

  1. What pieces of Sleuth will we need beyond the obvious classes in the Sleuth instrument packages?
  2. Are there any other options or recommendations?

Thanks in advance!


Solution

  • Micrometer does not yet support Kafka for our use case.

    Spring Kafka is instrumented, if you use that, you will get metrics and spans.

    We found this issue opened by Marcin Grzejszczak https://issues.apache.org/jira/browse/KAFKA-15191 Which proposes adding Micrometer instrumentation to kafka. Looks like there has not been any activity on it

    Since a lot of Apache projects are tracking user interaction and feedback, if you make some activity on it (i.e.: add a comment that you as a Kafka user want this), Kafka devs might consider accepting a PR or implementing it.

    Idea #1: We're exploring the possibility of forking Sleuth code and eliminating pieces we don't need.

    I think this is not a good idea. Also Micrometer Tracing is a copy of Sleuth without the Spring dependencies, the instrumentation of Spring Kafka that lived in Sleuth was moved to Spring Kafka (were it should be).

    What pieces of Sleuth would we need? We know for sure we can exclude code for the integrations that we don't need.

    Again, I would not do this but you really want to, you would need the same pieces that we moved into Micrometer Tracing and the instrumentation pieces that was in Sleuth and now in Spring Kafka. Everything should be there for you, you "just" need to enable it. see:

    It's documented that Sleuth is not compatible with Spring Boot 3. Specifically, what areas would need to be remediated?

    I'm not sure anyone will be answer this question without actually doing the migration. :)

    What pieces of Sleuth will we need beyond the obvious classes in the Sleuth instrument packages?

    As far as I know, nothing, I would ask this question from you, is there anything that does not work if you use Micrometer Tracing and enable instrumentation in Spring Kafka?

    Are there any other options or recommendations?

    Use Micrometer Tracing and enable instrumentation in Spring Kafka.