It would be cool to have tracing on the initial dial request, but I think this would require a protocol-level enhancement to DialResponse (grpc).
The initial flow (happy path) looks like:
client -> server -> agent -[ endpoint ]- agent -> server -> client
It would be great to have latency information for each hop. In other words, something like:
- Server records
dial_req received timestamp (and server ID?)
- Agent records
dial_req received timestamp (and agent ID?)
- Agent records
endpoint dial complete timestamp
- Agent includes traces in the DialResponse
- Server records
dial_resp received timestamp
- Server adds request & response received timestamps to DialResponse
- Client constructs the full trace, records latency metrics for each hop, logs full trace at high verbosity
It looks like there's OpenCensus gRPC integration that we should investigate, but I'm not sure if it would be work with our multiplexed streams. At the very least, we should make sure our design fits the OpenCensus tracing spec
It would be cool to have tracing on the initial dial request, but I think this would require a protocol-level enhancement to
DialResponse(grpc).The initial flow (happy path) looks like:
It would be great to have latency information for each hop. In other words, something like:
dial_req receivedtimestamp (and server ID?)dial_req receivedtimestamp (and agent ID?)endpoint dial completetimestampdial_resp receivedtimestampIt looks like there's OpenCensus gRPC integration that we should investigate, but I'm not sure if it would be work with our multiplexed streams. At the very least, we should make sure our design fits the OpenCensus tracing spec