-
Notifications
You must be signed in to change notification settings - Fork 869
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
Add lettuce 5.2 instrumentation that uses lettuce's native tracing functionality. #535
Conversation
...rc/main/java8/io/opentelemetry/auto/instrumentation/lettuce/v5_2/LettuceClientDecorator.java
Outdated
Show resolved
Hide resolved
.../src/main/java8/io/opentelemetry/auto/instrumentation/lettuce/v5_2/OpenTelemetryTracing.java
Outdated
Show resolved
Hide resolved
.../src/main/java8/io/opentelemetry/auto/instrumentation/lettuce/v5_2/OpenTelemetryTracing.java
Outdated
Show resolved
Hide resolved
.../src/main/java8/io/opentelemetry/auto/instrumentation/lettuce/v5_2/OpenTelemetryTracing.java
Outdated
Show resolved
Hide resolved
when: | ||
ConnectionFuture connectionFuture = testConnectionClient.connectAsync(StringCodec.UTF8, | ||
new RedisURI(HOST, port, 3, TimeUnit.SECONDS)) | ||
StatefulConnection connection = connectionFuture.get() |
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 can block indefinitely, not good
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.
Don't tests have a test timeout?
when: | ||
ConnectionFuture connectionFuture = testConnectionClient.connectAsync(StringCodec.UTF8, | ||
new RedisURI(HOST, incorrectPort, 3, TimeUnit.SECONDS)) | ||
StatefulConnection connection = connectionFuture.get() |
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.
same here
"net.peer.ip" "127.0.0.1" | ||
"net.peer.port" port | ||
"db.type" "redis" | ||
"db.statement" "key<TESTSETKEY> value<TESTSETVAL>" |
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.
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.
Unfortunately the interface doesn't provide RedisURI
, I have filed an issue for it
I think user and db_index are less commonly used with redis and we can probably live without them for now.
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.
.../src/main/java8/io/opentelemetry/auto/instrumentation/lettuce/v5_2/OpenTelemetryTracing.java
Outdated
Show resolved
Hide resolved
...rc/main/java8/io/opentelemetry/auto/instrumentation/lettuce/v5_2/LettuceClientDecorator.java
Outdated
Show resolved
Hide resolved
.../src/main/java8/io/opentelemetry/auto/instrumentation/lettuce/v5_2/OpenTelemetryTracing.java
Outdated
Show resolved
Hide resolved
@Nullable private final Span parent; | ||
|
||
@Nullable private OpenTelemetryEndpoint endpoint; | ||
@Nullable private String name; | ||
|
||
@Nullable private List<Object> events; | ||
@Nullable private List<String> tags; |
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.
what do u think about replacing parent
, endpoint
, name
and tags
with Span.Builder
?
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.
Unfortunately had to keep name since spanBuilder doesn't allow setting it, and some awkwardness for endpoint, but it seems to still be worth it.
event(0) { | ||
eventName "redis.encode.start" | ||
} | ||
event(1) { | ||
eventName "redis.encode.end" | ||
} |
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.
are these events worth capturing, given they are not part of the semantic conventions?
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.
I tend to lean towards instrumenting what we can, and users can use a downstream mechanism, e.g. span processor, to remove fields they don't need. Might help someone and while data can be filtered, there's no way to work around the lack of instrumentation.
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.
Thanks! I realized that this instrumentation can be applied to 5.1 just fine, the new method on the SPI will just be ignored, so I reduced the version floor. It also made it simpler to restrict the instrumentation for 5.0 and 5.1.
.../src/main/java8/io/opentelemetry/auto/instrumentation/lettuce/v5_2/OpenTelemetryTracing.java
Outdated
Show resolved
Hide resolved
.../src/main/java8/io/opentelemetry/auto/instrumentation/lettuce/v5_2/OpenTelemetryTracing.java
Outdated
Show resolved
Hide resolved
@Nullable private final Span parent; | ||
|
||
@Nullable private OpenTelemetryEndpoint endpoint; | ||
@Nullable private String name; | ||
|
||
@Nullable private List<Object> events; | ||
@Nullable private List<String> tags; |
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.
Unfortunately had to keep name since spanBuilder doesn't allow setting it, and some awkwardness for endpoint, but it seems to still be worth it.
when: | ||
ConnectionFuture connectionFuture = testConnectionClient.connectAsync(StringCodec.UTF8, | ||
new RedisURI(HOST, port, 3, TimeUnit.SECONDS)) | ||
StatefulConnection connection = connectionFuture.get() |
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.
Don't tests have a test timeout?
event(0) { | ||
eventName "redis.encode.start" | ||
} | ||
event(1) { | ||
eventName "redis.encode.end" | ||
} |
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.
I tend to lean towards instrumenting what we can, and users can use a downstream mechanism, e.g. span processor, to remove fields they don't need. Might help someone and while data can be filtered, there's no way to work around the lack of instrumentation.
"net.peer.ip" "127.0.0.1" | ||
"net.peer.port" port | ||
"db.type" "redis" | ||
"db.statement" "key<TESTSETKEY> value<TESTSETVAL>" |
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.
Unfortunately the interface doesn't provide RedisURI
, I have filed an issue for it
I think user and db_index are less commonly used with redis and we can probably live without them for now.
} | ||
|
||
dependencies { | ||
compileOnly group: 'io.lettuce', name: 'lettuce-core', version: '5.2.0.RELEASE' |
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.
Shouldn't this be 5.1.0.RELEASE
?
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.
Yeah guess so
...t/groovy/io/opentelemetry/auto/instrumentation/lettuce/v5_1/LettuceReactiveClientTest.groovy
Show resolved
Hide resolved
...test/groovy/io/opentelemetry/auto/instrumentation/lettuce/v5_1/LettuceAsyncClientTest.groovy
Show resolved
Hide resolved
Codenarc seems to have crossed a threshold due to the package name having an underscore. But I notice this pattern throughout the repo - can we disable this check?
|
nice muzzle work! 😄
yes, please do |
Looks ready now :) |
…nctionality. (open-telemetry#535) * Copy Lettuce 5.0 to start 5.1 instrumentation * Begin tracing adapter implementation Co-authored-by: Dustin Neray <[email protected]> * Set floor to 5.2 instead * Move around * Finish * Cleanups * Instrument 5.1+ instead * Cleanup * 5.1 * Remove latestDepTest from lettuce-5.0 since we have a newer lettuce-5.1. * Remove * Remove package check * Spotless Co-authored-by: Dustin Neray <[email protected]>
If muzzle lets me through in one shot I'd be amazed :)
While
Tracing
was added in 5.1, including the command was added in 5.2, and it doesn't seeem worth branching on this since this is new instrumentation, I just went ahead and targeted 5.2.Differences in tracing
Fixes #408
Fixes #504