如何利用`upstream_rq_time`指标理解Envoy延迟及查询分位数？

1. 为什么分位数指标是时间序列而非单个数值？ #

upstream_rq_time.p25/p50/p95 是Envoy基于滑动时间窗口计算的统计值，默认情况下Envoy会每隔固定周期（比如10秒）输出当前窗口内的分位数结果。Prometheus抓取这些数据后，自然会形成时间序列——每个数据点对应某个时刻滑动窗口的统计结果。

如果需要单个数值，你可以通过PromQL聚合最近一段时间的数据：

• 取最近一小时内的最后一个分位数值：last_over_time(upstream_rq_time.p95[1h])
• 取最近一小时内的平均分位数值：avg_over_time(upstream_rq_time.p95[1h])

2. 直方图视图下不同分位数几乎一致的原因 #

出现这种情况通常有以下几种可能：

• 延迟分布极度集中：你的上游请求延迟几乎都落在同一个区间，比如99%的请求延迟都在10ms以内，导致p25/p50/p95的差异极小，直方图看起来重合。
• Envoy直方图桶配置过粗：如果Envoy默认的upstream_rq_time桶区间设置得太宽泛（比如只分0-100ms、100ms-1s、1s+几个桶），不同分位数可能都落在同一个桶里，无法区分差异。可以通过调整Envoy的统计配置，增加更细粒度的桶。
• 样本量不足：如果时间窗口内的请求量太少，统计出来的分位数结果不稳定，甚至出现不同分位数趋同的情况。
• Grafana配置错误：确认你是否误选了相同的分位数指标，或者直方图的分组/聚合方式没有正确区分不同分位数。

3. 用Prometheus获取最近一小时的分位数延迟值 #

这里分两种情况处理：

情况一：使用Envoy原生直方图指标（推荐） #

Envoy默认会暴露envoy_upstream_rq_time_bucket（桶计数）、envoy_upstream_rq_time_sum（总耗时）、envoy_upstream_rq_time_count（总请求数）这三个直方图指标。你可以用Prometheus的histogram_quantile函数计算任意分位数：

# 计算最近1小时的p25延迟
histogram_quantile(0.25, sum(rate(envoy_upstream_rq_time_bucket[1h])) by (le, upstream_cluster))

# 计算最近1小时的p50延迟
histogram_quantile(0.5, sum(rate(envoy_upstream_rq_time_bucket[1h])) by (le, upstream_cluster))

# 计算最近1小时的p95延迟
histogram_quantile(0.95, sum(rate(envoy_upstream_rq_time_bucket[1h])) by (le, upstream_cluster))

• rate(envoy_upstream_rq_time_bucket[1h])：计算1小时内每个桶的请求速率
• sum(...) by (le, upstream_cluster)：按桶边界（le）和上游集群聚合（如果有多个Envoy实例或上游集群）
• histogram_quantile(分位数, 聚合后的桶数据)：计算目标分位数

情况二：使用预计算的分位数指标（如upstream_rq_time.p25） #

如果你的监控系统已经有预计算的分位数指标，直接用时间聚合函数获取最近1小时的结果即可：

# 取最近1小时内的最后一个p25值
last_over_time(upstream_rq_time.p25[1h])

# 取最近1小时内的平均p25值
avg_over_time(upstream_rq_time.p25[1h])

内容的提问来源于stack exchange，提问作者hitchhiker