4. 延迟类SLI口径设计：请求延迟、服务端延迟、网络延迟、端到端延迟的测量口径

延迟是衡量系统响应速度的核心指标，也是SRE黄金信号之一。不同观测视角下的延迟含义差异巨大：客户端感知的“慢”与服务端统计的“快”可能同时成立。本章从四个关键口径出发，逐一拆解其测量边界、统计方法与常见陷阱。

4.1 延迟SLI的四类口径概览

4.2 请求延迟：客户端视角的“真实感受”

请求延迟（Request Latency）在客户端侧测量，包含完整的网络往返时间（RTT）、服务端处理时间、以及响应数据传输时间。这是用户直接感知的延迟。

• 测量点：浏览器/移动端SDK/API网关出口
• 统计口径：从TCP连接建立（或HTTP请求发出）到最后一个字节接收完毕
• 常见陷阱：客户端DNS解析时间、TLS握手时间是否计入？建议单独记录，避免与业务延迟混淆
• 推荐分位：p50（中位数）、p95（第95百分位）、p99（第99百分位）

# 请求延迟计算示例（PromQL风格）
# 客户端侧：请求开始到结束的时间差
request_latency_seconds = request_end_timestamp - request_start_timestamp

# 按分位聚合（假设已记录到histogram）
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

4.3 服务端延迟：排除网络干扰的“纯处理时间”

服务端延迟（Server Latency）仅测量服务进程内部的处理耗时，排除网络传输、客户端排队等外部因素。它是容量规划和性能优化的核心依据。

• 测量点：服务框架拦截器/中间件（如Spring Filter、gRPC Interceptor）
• 统计口径：从请求到达服务进程（反序列化完成）到响应发出（序列化开始前）
• 常见陷阱：线程池排队等待时间是否计入？建议区分“队列等待”与“实际处理”，分别记录
• 推荐分位：p50、p99、p999（用于识别长尾）

4.4 网络延迟：基础设施的“传输代价”

网络延迟（Network Latency）衡量数据包在网络上传输的单向或往返耗时。它通常由网络设备、链路距离、拥塞程度决定，与应用代码无关。

4.5 端到端延迟：用户体验的“最后一公里”

端到端延迟（End-to-End Latency）从用户发起操作开始，到用户界面完成渲染或反馈结束。它包含客户端处理、网络传输、服务端处理、以及前端渲染的全部环节。

• 测量点：真实用户监控（RUM）、合成监控（Synthetic Check）
• 统计口径：用户点击 → 页面首屏渲染 / API响应展示
• 常见陷阱：前端JavaScript执行时间、图片懒加载、客户端缓存命中是否计入？建议按“关键用户操作”定义测量边界
• 推荐分位：p75（用户体验基线）、p95（容忍上限）、p99（不可用阈值）

# 端到端延迟分解（示例：Web页面加载）
e2e_latency = dns_lookup + tcp_connect + tls_handshake + 
              request_network + server_processing + 
              response_network + dom_parsing + resource_loading + 
              javascript_execution + rendering

4.6 四类延迟口径的关联与对比

以下SVG图展示了一个典型HTTP请求从客户端到服务端再到客户端的完整路径，并标注了四类延迟的测量边界。

4.7 口径选择决策矩阵

在实际SLI设计中，应根据SLO目标和观测角色选择合适口径。以下矩阵帮助快速决策：

4.8 延迟口径设计的常见陷阱与避坑

• 陷阱1：时钟不同步——分布式系统中各节点时钟偏差会导致延迟计算错误。解决方案：使用NTP对齐，或采用客户端单点打时间戳（如HTTP请求头记录时间）。
• 陷阱2：排队时间归属不清——请求在负载均衡器、线程池、消息队列中的等待时间应单独记录，避免与服务端处理时间混淆。
• 陷阱3：长尾请求被平均掩盖——仅看平均延迟会掩盖p99甚至p999的异常。必须使用分位统计，并设置独立的SLO阈值。
• 陷阱4：重试请求污染统计——客户端自动重试会导致延迟分布失真。建议在SLI中标记重试请求，或仅统计首次请求。
• 陷阱5：缓存命中与未命中混在一起——缓存命中请求的延迟远低于未命中请求。建议分别统计，或按缓存状态分层。

以下SVG图展示了一个完整的延迟分解结构，帮助理解各环节的归属关系。