-
Notifications
You must be signed in to change notification settings - Fork 867
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
fix: add attributes of net.peer.* for grpc client span #5324
Conversation
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.
nice! I didn't notice that we had a repro for this issue in the tests themselves 👍
@@ -56,7 +58,8 @@ | |||
} | |||
} | |||
|
|||
SocketAddress address = result.getAttributes().get(Grpc.TRANSPORT_ATTR_REMOTE_ADDR); | |||
URI uri = GrpcUtil.authorityToUri(next.authority()); |
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.
Let's just call URI
constructor itself (and not throw on an invalid one)
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!
SocketAddress address = null; | ||
try { | ||
URI uri = new URI(null, next.authority(), null, null, null); | ||
address = new InetSocketAddress(uri.getHost(), uri.getPort() == -1 ? 80 : uri.getPort()); |
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.
Won't calling the InetSocketAddress
constructor cause DNS resolution here? Should we use InetSocketAddress.createUnresolved()
instead?
On the other hand - it's a client instrumentation, so in theory the address should already be resolved - is that the case here? Or is the intercept method called earlier than that?
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.
On the other hand - it's a client instrumentation, so in theory the address should already be resolved - is that the case here? Or is the intercept method called earlier than that?
Yes, I found that invoked result.getAttributes().get(Grpc.TRANSPORT_ATTR_REMOTE_ADDR)
will return null
. But in TracingClientCallListener#onMessage
method, invoked it will get the expected result. So the root cause should be result.getAttributes()
called too early.
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.
@ralphgj I think the concern here is that calling new InetSocketAddress will trigger the host name to be resolved to an IP address, which we try to avoid triggering from instrumentation
InetSocketAddress.createUnresolved()
is probably safer unless we are clear this won't be a problem
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.
Got it. I tried and then found the attributes in spans without net.peer.ip
. Shall we go on using InetSocketAddress.createUnresolved()
instead?
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.
ya, it's ok not to capture net.peer.ip
...brary/src/main/java/io/opentelemetry/instrumentation/grpc/v1_6/TracingClientInterceptor.java
Outdated
Show resolved
Hide resolved
thx @ralphgj! |
Try to resolve #5178