2. 延迟（Latency）指标设计：请求延迟分位数、延迟分布与容器化下的延迟分离
延迟是衡量系统响应速度的核心指标。在容器化环境中，由于网络栈的虚拟化、共享内核以及调度抖动，延迟的构成比物理机更复杂。本章聚焦于如何设计有效的延迟指标，包括分位数选择、分布可视化，以及将网络延迟与处理延迟进行分离的方法。
2.1 延迟分位数：p50、p90、p99 的选择与含义
平均延迟（Average Latency）容易掩盖长尾问题，因此 SRE 实践中普遍使用分位数（Percentile）来描述延迟分布。下表总结了三个关键分位数的典型用途与容器化环境下的关注点：
| 分位数 | 含义 | 容器化环境典型关注点 | 告警阈值建议 |
|---|---|---|---|
| p50（中位数） | 50% 的请求在此值以下完成 | 反映大多数用户的体验基线；容器调度抖动可能导致 p50 小幅波动 | 基线 + 50% |
| p90 | 90% 的请求在此值以下完成 | 识别容器间资源争抢（CPU Throttling、内存 Swap）的影响 | 基线 + 100% |
| p99 | 99% 的请求在此值以下完成 | 捕捉冷启动、网络策略延迟、宿主机过载等极端事件 | 基线 + 200% 或值（如 500ms） |
实践建议：在容器化环境中，优先监控 p99 而非 max。max 值通常由单次异常事件（如 GC 停顿）触发，不具备可操作性。p99 能稳定反映长尾问题的严重程度，且更适合作为 SLO 的衡量基准。
2.2 延迟分布：从直方图到热力图
仅靠几个分位数无法完整描述延迟特征。延迟分布（Latency Distribution）通过直方图或热力图展示请求在不同延迟区间内的计数，帮助识别多峰分布、周期性抖动或渐进式劣化。
下图展示了一个典型的容器化服务延迟分布直方图，其中出现了两个明显的峰值：
关键洞察：如果延迟分布呈现双峰或多峰，通常意味着存在两种或多种不同的延迟来源（如本地缓存命中 vs. 远程调用、正常请求 vs. 冷启动请求）。此时，仅靠 p99 无法区分问题根因，必须对延迟进行分层拆解。
2.3 容器化下的延迟分离：网络延迟 vs. 处理延迟
在容器化环境中，一个请求的总延迟（End-to-End Latency）由多个阶段组成。如果不进行分离，当延迟升高时，无法快速判断是网络路径问题还是应用处理瓶颈。下图展示了容器化请求延迟的典型构成：
2.4 延迟分离的埋点策略
要在容器化环境中实现网络延迟与处理延迟的分离，需要在请求路径的关键节点插入时间戳。以下是一个通用的埋点流程：
- 入口网关/Ingress 层：记录请求到达时间
T1。 - Sidecar 代理（如 Envoy）：记录请求进入 Pod 的时间
T2，以及请求到达应用进程的时间T3。 - 应用层：记录请求开始被业务逻辑处理的时间
T4，以及处理完成的时间T5。 - 响应路径：反向记录
T6（Sidecar 发出）、T7（Ingress 发出）。
通过上述时间戳，可以计算出以下关键指标：
| 指标 | 计算公式 | 含义 |
|---|---|---|
| 网络延迟（入站） | T4 - T1 |
从客户端到应用进程的网络耗时，包含容器网络开销 |
| 处理延迟 | T5 - T4 |
应用实际执行业务逻辑的时间 |
| 网络延迟（出站） | T7 - T6 |
响应回传的网络耗时 |
| Sidecar 开销 | (T3 - T2) + (T6 - T5) |
Service Mesh 代理引入的额外延迟 |
注意：时间戳同步问题。在分布式容器环境中，不同 Pod 之间的时钟可能存在偏移。建议使用单调递增时钟（
CLOCK_MONOTONIC）而非墙上时钟，并在同一进程内完成延迟计算，避免跨节点时间戳直接相减。
2.5 容器化环境特有的延迟抖动源
除了常规的网络和应用延迟，容器化环境还引入了以下特有的延迟抖动源，需要在指标设计中单独捕获：
- CPU Throttling：当容器 CPU 使用超过 CFS 配额时，内核会强制限流，导致处理延迟突然升高。应监控
cpu_throttled_seconds_total。 - 网络策略延迟：Calico/Cilium 等 CNI 插件在首次建立连接时可能需要查询 API Server 或更新 eBPF 映射，造成首包延迟（P50 升高）。
- 冷启动延迟：当 Pod 被重新调度或扩缩容时，新启动的容器需要加载依赖库、建立连接池，导致 p99 在短时间内飙升。
- NUMA 跨节点访问：在大型宿主机上，如果容器被调度到非本地 NUMA 节点，内存访问延迟会增加 20%-50%。
实战案例：某团队发现 p99 延迟每周三下午出现规律性尖峰。通过分离网络延迟与处理延迟，发现处理延迟正常，但网络延迟在尖峰时段增加了 300ms。进一步排查发现，尖峰时段恰好是集群内所有 Pod 同时进行日志轮转（Log Rotation），导致宿主机磁盘 I/O 拥塞，进而影响了容器网络数据包的写入。解决方案是将日志轮转改为随机延迟执行。
2.6 延迟指标设计的 Golden 配置清单
以下是在 Prometheus + Grafana 体系下，针对容器化环境推荐的延迟指标配置清单：
| 指标名称 | 类型 | 标签建议 | 采集频率 | 保留周期 |
|---|---|---|---|---|
http_request_duration_seconds |
Histogram | service, pod, method, path, status_code | 10s | 30d |
network_latency_seconds |
Summary | source_pod, dest_pod, protocol | 15s | 14d |
processing_latency_seconds |
Histogram | service, handler, pod | 10s | 30d |
sidecar_overhead_seconds |
Gauge | pod, sidecar_version | 30s | 7d |
通过以上配置，SRE 团队可以在容器化环境中实现延迟的精细化监控，快速定位是网络路径、应用处理还是基础设施导致的延迟劣化，从而更高效地进行根因分析与容量规划。