search

grpc / grpc-java

The Java gRPC implementation. HTTP/2 based RPC
https://grpc.io/docs/languages/java/
Apache License 2.0
11.35k stars 3.81k forks source link

Capture more information on error for debugging #2815

Open ejona86 opened 7 years ago

ejona86 commented 7 years ago

When an error is propagated to the application, it would be useful to have things like server IP address[1], the timeout of the call (deadline - now), and whether the error was generated on the server.

There is other information that gRPC doesn't have direct knowledge of being useful, like tracing ids. Either Metadata would need to be included in full (doesn't sound great to me, since that could include auth tokens) or we could allow interceptors to cheaply supplement the data.

  1. Note that retries/hedging make "address" a bit more interesting.
jhspaybar commented 7 years ago

I'd also like this information to somehow make it back to load balancers so errors and latency can be used in load balancing decisions.

ejona86 commented 7 years ago

@jhspaybar, this issue is more for human consumption. I think we'd make it a string or some other unhelpful-for-you form. And the LB doesn't see the status already, and we'd likely put this information "close" to the status. So you'd probably want a separate issue to track it. #2717 tracks the RTT latency, but that's different from the RPC latency.