You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.
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.
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:]
The text was updated successfully, but these errors were encountered: