HTTP CONNECT latency measurements

[sfc-gh-jrewerts]

Title: HTTP CONNECT latency measurements

Description:
I'm using Envoy to act as a proxy server for long lived TCP connections. The way this works is our client sends an HTTP CONNECT to our proxy. When the response is returned, we keep the connection open. From what I can see, our downstream_rq_time metric measures the life of the connection, not when the request is received by the client. Is this expected? Are there any recommendations for measuring latency in cases where connections live for hours or days like this?

[optional Relevant Links:]

• Emitting metrics for TCP round trip time #39136 - a question on measuring RTT

[phlax]

cc @mattklein123 @jmarantz

[jmarantz]

Same issue as TCP latency. How would Envoy know what the request boundaries are?

[sfc-gh-jrewerts]

Yeah thinking about it a bit more, it definitely makes sense. Are there any recommendations on measuring latency in these strange edge cases? We still have packets flowing through Envoy, it'd be great to get some insight into how long it takes for the upstream and the downstream to respond.

[sfc-gh-jrewerts]

Feel free to close this issue if nothing exists today, I can focus on using tcp_info to provide the telemetry if needed.

[yanavlasov]

The best you can do is to report TCP RTT values, which are not currently exposed to access log. So unfortunately there are no values that Envoy can log for your case.

[sfc-gh-jrewerts]

I ended up finding tcp_stats, which appears to do what I need. Source for reference. From what I can see, this should let me see downstream RTT and upstream RTT.