-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Micrometer#observation(): avoids scopes, set parentObservation #3119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This commit reworks the reactor-core-micrometer module in several ways: - made the context-propagation dependency optional - added `Micrometer#isContextPropagationAvailable` to detect it at runtime - also added `Micrometer#isTracingAvailable` as a bonus - reworked MicrometerObservationListener to check context-propagation is available and fallback to exclusively use Reactor Context to deal with Observation hierarchy: - read Observation from Context - don't open a scope, but rather start new Observation setting old one as parent explicitly - store the new Observation in the ContextView - when context-propagation is there, focus on Micrometer.Observation ContextSnapshot key using a predicate in eg. `captureUsing`
reactor-core-micrometer/src/main/java/reactor/core/observability/micrometer/Micrometer.java
Outdated
Show resolved
Hide resolved
...meter/src/main/java/reactor/core/observability/micrometer/MicrometerObservationListener.java
Outdated
Show resolved
Hide resolved
| //tap context hasn't been initialized yet, so addToContext can now use the Scope | ||
| ContextSnapshot contextSnapshot2 = ContextSnapshot.capture(this.originalContext); | ||
| this.contextWithScope = contextSnapshot2.updateContext(Context.of(this.originalContext)); | ||
| if (Micrometer.isContextPropagationAvailable()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might not always work very well. I think in some cases debuggers can introspect local variables which would cause classpath issues if context-propagation is not there. We tend to isolate such blocks of code in static, nested classes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you elaborate? I'm not sure what and how to isolate at this level...
...gationTest/java/reactor/core/observability/micrometer/MicrometerObservationListenerTest.java
Outdated
Show resolved
Hide resolved
...gationTest/java/reactor/core/observability/micrometer/MicrometerObservationListenerTest.java
Outdated
Show resolved
Hide resolved
...r/src/test/java/reactor/core/observability/micrometer/MicrometerObservationListenerTest.java
Outdated
Show resolved
Hide resolved
…f Context-Propagation API
|
following the reviews and a long discussion with @marcingrzejszczak, I've reworked this quite a bit and the We've decided that removing all So the |
|
side note on the usage of (at a point I had a test suite without context-propagation, and it was running fine while accessing KEY. this test suite has been rolled back however) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks much more straight-forward. I like that it's possible to just work with the Reactor Context as expected within a Reactor chain.
...meter/src/main/java/reactor/core/observability/micrometer/MicrometerObservationListener.java
Outdated
Show resolved
Hide resolved
…omments, add KEY smoke test
This commit reworks the reactor-core-micrometer module in several ways:
as parent explicitly
outdated
Micrometer#isContextPropagationAvailableto detect it atruntime
Micrometer#isTracingAvailableas a bonusis available and fallback to exclusively use Reactor Context to deal
with Observation hierarchy:
ContextSnapshot key using a predicate in eg.
captureUsing