Comment by otterley
6 hours ago
Could you not have gotten all this information by changing the Envoy log format to add the required fields? In your blog post, you show the default log format, and suggest that there was no way whatsoever to get this data from the logs. But according to the documentation, Envoy has rich support for many additional fields including detailed latency statistics.
I wonder if you added complexity to the architecture when a simple log format change would have sufficed.
To my knowledge, Envoy does not provide this type of information for TCP proxying. I wanted request/response latency, but the available metrics are limited to connection-level information
Why aren’t you using HTTP proxying if the underlying protocol is HTTP?
TCP proxying, in my experience, is typically only used for routing TLS or other non-HTTP TCP requests. In the former case, the proxy should not be able to observe the requests and responses.
We currently only provide TCP load balancers, so HTTP-level proxying was not an option. Since the customer was not using TLS, this solution worked.