4. 延迟定义与度量：延迟的四个黄金信号、P50/P90/P99 百分位含义、Istio 内置指标

在服务网格的延迟诊断中，定义清晰、度量准确是定位瓶颈的前提。本章将建立延迟的度量体系，涵盖四个黄金信号中的延迟维度、百分位统计方法，以及 Istio 内置的 istio_request_duration_milliseconds 指标。

4.1 延迟的四个黄金信号

Google SRE 经典著作《Site Reliability Engineering》提出了监控的四个黄金信号：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。在 Istio 服务网格中，延迟是衡量用户体验和系统健康度的首要指标。

4.2 P50 / P90 / P99 百分位含义

平均延迟（Average Latency）容易掩盖长尾问题。百分位（Percentile）度量能更真实地反映用户体验。

• P50（中位数）： 50% 的请求延迟低于此值。代表“典型”用户体验。
• P90： 90% 的请求延迟低于此值。代表“大多数用户”体验，常用于 SLA 定义。
• P99： 99% 的请求延迟低于此值。代表“最差 1% 用户”体验，用于捕捉长尾问题。
• P999： 99.9% 的请求延迟低于此值。用于极高性能场景（如金融交易）。

4.3 Istio 内置指标：istio_request_duration_milliseconds

Istio 通过 Envoy 代理自动生成丰富的延迟指标，核心指标为 istio_request_duration_milliseconds。该指标是一个 Histogram（直方图） 类型，记录了请求从 Envoy 收到完整请求头到发送完整响应头之间的耗时。

4.3.1 指标结构

istio_request_duration_milliseconds_bucket{
  destination_service="reviews.default.svc.cluster.local",
  destination_version="v2",
  response_code="200",
  reporter="destination",
  source_workload="productpage",
  le="100"   // 桶上界（单位：毫秒）
} 1024

istio_request_duration_milliseconds_sum{
  destination_service="reviews.default.svc.cluster.local",
  ...
} 204800.0

istio_request_duration_milliseconds_count{
  destination_service="reviews.default.svc.cluster.local",
  ...
} 1024

4.3.2 关键标签（Labels）

• destination_service / destination_version： 目标服务及版本，用于定位慢服务或异常版本。
• source_workload： 调用方工作负载，用于识别“问题调用者”。
• response_code： HTTP 响应码，区分正常与错误请求的延迟。
• reporter： 指标上报方，source（客户端视角）或 destination（服务端视角）。

4.3.3 计算百分位：PromQL 示例

使用 histogram_quantile 函数从直方图计算百分位延迟：

// P99 延迟（毫秒）
histogram_quantile(0.99,
  sum(rate(
    istio_request_duration_milliseconds_bucket{
      reporter="destination",
      destination_service="reviews.default.svc.cluster.local"
    }[1m]
  )) by (le, destination_version)
)

// P90 延迟
histogram_quantile(0.90,
  sum(rate(
    istio_request_duration_milliseconds_bucket{
      reporter="destination"
    }[1m]
  )) by (le, destination_service)
)

4.4 延迟诊断的度量策略

1. 分层度量： 分别监控 P50、P90、P99，观察延迟分布形态。
2. 对比度量： 对比 source 与 destination 的延迟，识别网络开销。
3. 维度下钻： 按 destination_version、response_code 拆分，定位慢版本或错误延迟。
4. 基线对比： 与历史同期数据对比，发现异常波动。