You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have you considered any alternatives or workarounds?
No workarounds at this point that I'm aware of.
Any additional context
If we're scanning users' business code then most likely all timers are related to business operations that should be within an actual tracing scope. That means that conversion from a timer to an observation with having e.g. Micrometer Tracing on the classpath will result in creation of a child span and that's a great outcome.
The problem we can face is if there are any timers in infrastructure part of the code. Those might maybe be kept as timers (e.g. time required to start the application - we don't want that to become a span). I doubt however that we are able to get this information from scanning the code.
This recipe should be applicable only if micrometer-core JAR is on the classpath (that contains the Timer class). If we want to migrate to Micrometer Observation then micrometer-observation JAR must be present on the classpath.
Check the Micrometer Docs for more information about Micrometer Observation.
Quick note to say I'm reading up, and have started to define the scenarios (not) to convert in #2; welcome to follow along and chime in there with further cases to cover.
What problem are you trying to solve?
Convert Micrometer Timer to a Micrometer Observation (cc @shakuzen @jonatan-ivanov).
NOTE: This feature request is temporarily set in
rewrite-spring
but since it's related to Micrometer it has nothing to do with Spring.What precondition(s) should be checked before applying this recipe?
Java projects.
Describe the situation before applying the recipe
.Example using Timer Builder
.Example using Sample
.Example using Wrap + Run
.Example for different timers in the same class
Describe the situation after applying the recipe
. Solution for Example2, Example3, Example4
. Solution for ExampleWithDifferentMeters
Have you considered any alternatives or workarounds?
No workarounds at this point that I'm aware of.
Any additional context
If we're scanning users' business code then most likely all timers are related to business operations that should be within an actual tracing scope. That means that conversion from a timer to an observation with having e.g. Micrometer Tracing on the classpath will result in creation of a child span and that's a great outcome.
The problem we can face is if there are any timers in infrastructure part of the code. Those might maybe be kept as timers (e.g. time required to start the application - we don't want that to become a span). I doubt however that we are able to get this information from scanning the code.
This recipe should be applicable only if
micrometer-core
JAR is on the classpath (that contains theTimer
class). If we want to migrate to Micrometer Observation thenmicrometer-observation
JAR must be present on the classpath.Check the Micrometer Docs for more information about Micrometer Observation.
Are you interested in contributing this recipe to OpenRewrite?
We can definitely help with guidance on how to do this feature.
The text was updated successfully, but these errors were encountered: