Open guydc opened 4 days ago
seems reasonable, although if a connection is being reused in a HTTP request it'd probably be 0s for those.
seems reasonable, although if a connection is being reused in a HTTP request it'd probably be 0s for those.
Actually, from testing, it seems that the time points are preserved for all requests in a given connection. So, each request would show the duration that was initially required to setup the upstream connection, which could be a bit misleading for users.
Description: Envoy currently records several upstream connection time points that are not supported by the
%COMMON_DURATION(...)%
operator: https://github.com/envoyproxy/envoy/blob/2c84739549e6875aa1bac2983e7a0c43725f77e9/envoy/stream_info/stream_info.h#L352-L354These timestamps are useful for identifying the overhead of upstream TCP/TLS connection establishment. The
%UPSTREAM_CONNECTION_POOL_READY_DURATION%
operator provides the total connection establishment time, but it does not distinguish between the TCP and TLS parts and is only available in millisecond resolution. The above-mentioned time points can be supported in the%COMMON_DURATION(...)%
operator to achieve that.