Linkerd 服务网格怎样读取请求级延迟指标

读取 Linkerd 请求延迟，可以先用 linkerd viz stat 查看指定工作负载和时间窗口的p50、p95、p99，再到 Prometheus 查看代理导出的延迟直方图。这里的“请求级”表示基于HTTP或gRPC请求的观测，不表示每一条请求都保存在指标中。尤其要注意：response_latency_ms 统计首个响应数据到达的延迟，不等于完整响应体传输耗时。

官方地址：https://linkerd.io/docs/reference/proxy-metrics/

本文按一个“用户觉得慢，网格延迟却不高”的假设场景展开，解释当前官方资料中的读取方式与判断顺序。没有运行集群命令，也没有真实故障数据；文中的资源名称应替换为自己的部署。

先判断要看延迟分布还是单次请求

排查前先把问题写具体。如果要知道最近一段时间某个服务的慢请求情况，应看延迟分布。如果要知道某个订单请求在哪个调用环节等待，则需要关联访问日志或分布式追踪。一个p99数值无法还原那条请求的完整调用链。

p50是中位位置，p95和p99用于观察分布尾部；它们都不是算术平均值。把p99理解成“最慢那条请求”也不准确。流量很少时，尾部分位数的解释应更谨慎，并结合请求量一起看。

从工作负载视角读取窗口指标

假设业务命名空间叫 checkout-demo，部署叫 checkout-api，可参考下面的只读命令。前提是环境已有可用的Linkerd与Viz观测链路，工作负载流量经过代理，并且当前身份有读取权限。

# 示例读取部署最近5分钟统计，不是本文的实际执行记录。
linkerd viz stat deploy/checkout-api -n checkout-demo --time-window 5m

先确认资源和命名空间，再一起读请求量、成功率与延迟。若显示空值，不应立刻写成“延迟为0”。窗口没有合适样本、代理没有观测到协议流量或指标尚未采集，都可能让数值不可用。

这个读取结果是所选资源的聚合视图。若客户端还经过入口代理、网络或其他服务，用户耗时不能与这一行统计直接等同。换成另一种资源或方向前，应记录原来的观察位置，避免把视角变化误判为性能变化。

读懂直方图的单位和采样边界

代理指标默认以Prometheus格式暴露在指标端口4191的 /metrics。读取已配置的指标存储时，应先确认抓取来源，避免把不同代理、方向或服务的数据混为一组。

response_latency_ms 是直方图，单位是毫秒。其计量起点是代理处理请求头，终点是首个响应数据帧；没有响应数据时使用流结束事件。服务立即返回响应头但迟迟不发响应体数据的情况，也包含在这一口径中。

直方图的桶是累计分布，不是单请求列表。基于桶计算分位数时，应保留桶边界维度，对适当窗口的增量速率进行聚合；不能直接把不同Pod的p99求平均，也不能把桶计数误读成延迟值。结果仍应以该指标的毫秒单位解释。

还要分清采样终点和导出时机。官方说明，延迟观测不会在响应流结束之前导出到Prometheus。长连接或长流式响应因此可能延后进入统计；不能因为某条流正在运行而指标暂未变化，就判断它没有延迟。

指标为空或与用户耗时不同时怎样定位

先看流量是否经过代理。绕过代理的端口无法提供同样的网格观测；只有TCP层信息时，也不能期待HTTP请求分位数。接着确认抓取链路与时间窗口，而不是先调大业务超时。

当“用户慢、网格首字节不慢”时，可以把假设分成两类：首个数据很快但后续响应体很慢；或者等待发生在所选代理观察范围之外。大文件下载和流式接口尤其容易出现第一种情况。这只是排查方向，不能据一个指标直接判定根因。

方向也影响观察范围。服务端入站视角和客户端出站视角不是同一条计时边界；重试还可能让一个业务请求对应多个后端尝试。比较之前，应明确看的是哪一层请求、是否涉及重试，不能把请求量差异当成重复抓取的唯一证据。

调整后怎样作同口径比较

如果最终调整了应用、网络或代理配置，应使用相同资源、方向、时间窗口和负载条件再次观察。除了尾延迟，还要记录成功率和请求量，避免因为失败更多或流量减少而得到更漂亮的延迟。

p50能代替平均延迟吗？不能。中位数与平均数回答不同问题。

能从直方图找出具体请求ID吗？不能。需要与日志或追踪记录关联。

旧版和新版代理一定有相同指标吗？不要这样假设。具体指标名、标签和能力应对应实际代理版本，尤其不要把不同延迟定义混合计算。

参考：代理指标定义；Viz命令参考；遥测与监控说明；观测入口说明。