-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
HBASE-26521 Name RPC spans as $package.$service/$method
#4024
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
hbase-client/src/main/java/org/apache/hadoop/hbase/client/trace/IpcClientSpanBuilder.java
Outdated
Show resolved
Hide resolved
hbase-client/src/main/java/org/apache/hadoop/hbase/client/trace/IpcClientSpanBuilder.java
Outdated
Show resolved
Hide resolved
hbase-client/src/main/java/org/apache/hadoop/hbase/client/trace/IpcClientSpanBuilder.java
Outdated
Show resolved
Hide resolved
2df6379
to
0571aaf
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
attributes.put(RPC_METHOD, method); | ||
} | ||
|
||
private static String getRpcPackageAndService(final Descriptors.MethodDescriptor md) { |
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.
We could move this method to a util class and also let the IpcServerSpanBuilder to call this method too? So in the future if we want to change the implementation, we could fix them both at the same time.
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'm generally against "util" classes. They indicate to me a lack of proper object/interface design and separation of concerns. I also prefer that test code reuse as little of the implementation code as is necessary -- and no more. The reason being that test code usually needs to test output behaviors. When test code and implementation share the same code for computing those behaviors, it nullifies the point.
Let me see what makes sense for these methods.
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 follow this strategy in the latest patch. IpcServerSpanBuilder
has the details of how these tracing variables are extracted from the MethodDescriptor
instance. The test uses constant values rather than looking them up from some instance. I think this makes for a more robust test.
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.
But IpcServerSpanBuilder is not for testing only? It is what we need to use at server side? I can not follow...
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 misunderstood you. The latest commit consolidates the implementation for both IpcClientSpanBuilder
and IpcServerSpanBuilder
into IpcClientSpanBuilder
.
return md.getService().getFullName(); | ||
} | ||
|
||
private static String getRpcName(final Descriptors.MethodDescriptor md) { |
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.
Ditto.
return new FeatureMatcher<SpanData, T>(matcher, "SpanData having duration that ", "duration") { | ||
@Override | ||
@SuppressWarnings("unchecked") | ||
protected T featureValueOf(SpanData item) { |
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.
Looking at the implementation of java.time.Duration, it seems that it can only be compared with another Duration, so do we need to introduce a generic type here? Just use Duration directly?
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.
Sure, good point. I guess the T extends Comparable<T> & TemporalAmount
stuff is overly broad.
hbase-common/src/main/java/org/apache/hadoop/hbase/trace/HBaseSemanticAttributes.java
Show resolved
Hide resolved
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
0571aaf
to
9328e54
Compare
Hmm, backup/restore test failures. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
The failure of TestResult is because of HBASE-26688. Let me see how to address it. |
9328e54
to
e26a7b5
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
e26a7b5
to
762d866
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
attributes.put(RPC_METHOD, method); | ||
} | ||
|
||
private static String getRpcPackageAndService(final Descriptors.MethodDescriptor md) { |
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.
But IpcServerSpanBuilder is not for testing only? It is what we need to use at server side? I can not follow...
|
||
public IpcServerSpanBuilder(final RpcCall rpcCall) { | ||
this.rpcCall = rpcCall; | ||
// it happens that `getFullName` returns a string in the $package.$service format required by |
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 I mean is that, we have this logic in both IpcServerSpanBuilder and IpcClientSpanBuilder, as what you said in the comment, we may have to parse the value in the future then we need to modify both places. So I suggest that we have a common method to generate the span name from the ServiceDescriptor and MethodDescriptor.
Simplify `SpanDataMatchers#hasDuration` to work explicitly with `Duration` instances.
762d866
to
5680c8b
Compare
Further consolidate implementation extracting method information from protobuf objects.
5680c8b
to
b4bb876
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
remove unused import
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
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.
+1
Thanks Nick for the hard work!
And thank you @Apache9 for sticking with me through the reviews! |
Signed-off-by: Duo Zhang <zhangduo@apache.org>
Signed-off-by: Duo Zhang <zhangduo@apache.org>
Signed-off-by: Duo Zhang <zhangduo@apache.org>
Signed-off-by: Duo Zhang <zhangduo@apache.org>
Bring us into basic conformance with https://github.com/open-telemetry/opentelemetry-specification/blob/3e380e249f60c3a5f68746f5e84d10195ba41a79/specification/trace/semantic_conventions/rpc.md