Open sambsnyd opened 1 year ago
Yes, closer investigation reveals that there are quite a few differences at the lower level. However, I wonder how much of this should be covered by this migration recipe. I suspect that applications using the API are rather rare and those which do probably only use a small subset of the entire API. I propose to start with a recipe covering the main APIs and then try to validate the recipe on the public SaaS tenant against some projects using these APIs. What do you think, @sambsnyd ?
Depending on the exact version of Spring Cloud Sleuth the APIs are unfortunately also rather different. With the latest version they tried to align the APIs so that the migration to Micrometer Tracing would be as painless as possible.
Instead of implementing all possible version upgrades or anticipating some specific migration path, the current state of the recipes simply migrates from the latest Spring Cloud Sleuth v3.1.7 to Micrometer Tracing v1.0.3.
Recent versions of spring have moved from spring-sleuth to micrometer for instrumentation. See this migration guide: https://github.com/micrometer-metrics/tracing/wiki/Spring-Cloud-Sleuth-3.1-Migration-Guide
Our migration needs to add the dependency for micrometer-tracing if spring-sleuth is present, even transitively, in the dependency tree. spring-cloud-starter-sleuth went away after spring-boot 2, to be replaced by either micrometer-tracing-bridge-brave or micrometer-tracing-bridge-otel. Brave is older so existing code will almost certainly be using that. For our migration we can probably assume brave, and if there is demand someone can provide a separate brave -> otel migration.
ChangePackage
of brave -> io.micrometer.tracing is a first, rough, step for code changes. But there aren't 1:1 drop-in replacements for every single brave type. Will need to investigate and determine what the replacement types are at a more nuanced level.A list of still open issues:
spring.sleuth.web.skipPattern
as already reported in this issue