3. 控制面性能关键指标（KPI）：延迟、吞吐量、资源消耗、错误率、队列深度

在集群升级前，必须对 Service Mesh 控制面进行性能基线校准。控制面是网格的“大脑”，其性能直接决定 Sidecar 代理的配置下发速度、数据面的稳定性以及集群的整体可观测性。本节定义五个核心 KPI，作为基线采集与对比的量化依据。

3.1 五大核心 KPI 总览

下表列出了控制面性能基线的五大关键指标及其测量维度：

3.2 延迟（Latency）

延迟是衡量控制面响应速度的首要指标。在 Service Mesh 中，延迟主要体现为从服务实例发生变化到 Sidecar 接收到最新配置的时间差。

• XDS 推送延迟： 从 Endpoint/Cluster/Listener/Route 变更到 Pilot 完成推送的时间。
• Sidecar 确认延迟： 从 Pilot 推送完成到 Sidecar 返回 ACK 的时间。
• 端到端延迟： 服务注册变更 → 控制面感知 → 推送 → Sidecar 生效的完整链路。

延迟基线采集命令示例（Istio 环境）：

# 采集 Pilot 推送延迟（P99）
kubectl exec -n istio-system deploy/istiod -- \
  curl -s localhost:15014/metrics | \
  grep 'pilot_proxy_convergence_time' | \
  head -5

# 输出示例（单位：毫秒）
# pilot_proxy_convergence_time{type="eds"}[99.0] 342
# pilot_proxy_convergence_time{type="cds"}[99.0] 287

3.3 吞吐量（Throughput）

吞吐量反映控制面在单位时间内能处理的配置变更与 Sidecar 连接数量。升级前必须确认控制面吞吐量余量充足。

3.4 资源消耗（Resource Consumption）

控制面资源消耗直接影响集群的调度稳定性和运维成本。升级后若资源消耗异常增长，往往是配置模型变更或代码回归的信号。

• CPU： 关注 Pilot 容器的 CPU 使用率（User + Sys）以及 Go Runtime 的 GC 占用的 CPU 比例。
• 内存： 关注 RSS（常驻内存）和 Go Heap 大小。内存泄漏通常表现为 RSS 持续增长不回落。
• Go GC 暂停： 控制面使用 Go 语言实现，GC 暂停时间过长会导致推送延迟抖动。

资源消耗基线采集命令：

# 采集 Pilot 容器资源使用（Prometheus 查询）
rate(container_cpu_usage_seconds_total{namespace="istio-system", pod=~"istiod-.*"}[5m])
container_memory_rss{namespace="istio-system", pod=~"istiod-.*"}

# Go GC 暂停时间
go_gc_duration_seconds{quantile="0.99", job="pilot"}

3.5 错误率（Error Rate）

错误率是控制面健康状态的直接反映。在升级前基线中，错误率必须接近零。

3.6 队列深度（Queue Depth）

队列深度是控制面背压（Backpressure）的直接体现。当控制面处理能力跟不上请求速率时，未处理的推送任务会在内存中排队。

• 推送队列： Pilot 内部用于缓存待推送配置变更的队列长度。
• XDS 请求队列： 每个 Sidecar 的 gRPC 流对应的请求处理队列。
• 事件处理队列： 从 Kubernetes API Server 接收到的 Service/Endpoint 变更事件队列。

队列深度与系统稳定性的关系如下图所示：

3.7 基线采集与记录规范

为确保基线数据可对比、可回溯，建议按以下规范执行采集：

1. 采集周期： 至少连续采集 7 天，覆盖工作日与周末的业务高低峰。
2. 采集粒度： 指标采集间隔 ≤ 30 秒，Prometheus 存储保留 ≥ 30 天。
3. 场景标记： 在 Prometheus 指标中增加 baseline_scene="steady" 或 baseline_scene="stress" 标签。
4. 基线文档： 将 P50、P95、P99 值记录到版本控制系统中（如 Git），作为升级后的对比基准。