3. 性能指标总览：CPU使用率、内存占用、网络吞吐、磁盘IOPS、P99延迟、错误率等关键指标

在容器运行时治理与发布流水线跨环境迁移的场景中，性能曲线对账的核心前提是建立一套统一、可量化的指标观测体系。不同环境（开发、测试、预发、生产）的硬件规格、网络拓扑与负载特征存在差异，只有通过标准化指标集进行横向对比，才能准确识别性能劣化或异常漂移。

本章定义并解析容器迁移对账所需的六大关键性能指标，涵盖计算、内存、网络、存储、延迟与稳定性维度。每个指标均附带采集方式、单位说明及跨环境对账时的常见陷阱。

3.1 指标全景与分类

下表归纳了六大指标的分类、核心关注点及在迁移对账中的典型用途：

3.2 核心指标详解

3.2.1 CPU 使用率

CPU 使用率反映容器在单位时间内占用 CPU 时间的比例。在 Kubernetes 环境中，通常通过 container_cpu_usage_seconds_total 计算增量。迁移对账时需关注：

• 限制 vs. 请求： 对比两个环境的 CPU 资源规格（request/limit）是否一致，避免因资源争抢导致 CPU 节流（throttling）。
• 多核归一化： 使用百分比（如 200% 表示占用 2 核）时，需确认分母为实际分配的 CPU 核数。

3.2.2 内存占用

推荐使用 container_memory_working_set_bytes 作为内存占用指标，它剔除了缓存和可回收页，更接近实际使用量。迁移对账常见问题：

• 缓存差异： 新环境若使用不同存储引擎或文件系统，Page Cache 大小可能不同，导致内存占用曲线偏移。
• OOM 风险： 当内存占用接近 limit 时，需结合 P99 延迟曲线判断是否触发 OOM Kill。

3.2.3 网络吞吐

网络吞吐分为入站（inbound）和出站（outbound），单位通常为 Mbps 或 Gbps。跨环境迁移时，网络吞吐曲线对账能暴露：

• 带宽瓶颈： 若生产环境网络吞吐接近上限，而测试环境带宽充裕，则迁移后可能出现丢包。
• 协议开销： 服务网格（如 Istio）的 sidecar 代理会增加额外吞吐，需在基线中扣除。

3.2.4 磁盘 IOPS

IOPS（Input/Output Operations Per Second）衡量存储系统的并发处理能力。容器场景下，需区分读写 IOPS。对账要点：

• 存储后端差异： 本地 SSD、云盘（EBS/PD）、分布式存储（Ceph）的 IOPS 上限差异巨大，直接对比值无意义，应对比“IOPS 利用率”。
• IO 等待： 结合 container_fs_io_time_weighted 观察 IO 等待时间，判断存储是否成为瓶颈。

3.2.5 P99 延迟

P99 延迟表示 99% 的请求在多少毫秒内完成，是衡量用户体验的关键指标。迁移对账时，P99 延迟曲线通常作为“金丝雀”信号：

• 基线对齐： 在迁移前，需在生产环境采集至少 7 天的 P99 延迟基线。
• 异常检测： 若迁移后 P99 延迟升高超过 20%，应立即触发回滚或限流。

3.2.6 错误率

错误率通常指 HTTP 5xx 或业务自定义错误码的比例。迁移对账中，错误率曲线应保持零容忍：

• 瞬时错误： 迁移过程中可能因连接池重建、DNS 缓存失效产生短暂错误，需与持续错误区分。
• 慢启动： 新环境冷启动时，错误率可能短暂升高，需结合 P99 延迟曲线综合判断。

3.3 指标关联分析：从单指标到多维对账

单一指标无法完整反映迁移影响。下图展示了六大指标之间的典型关联关系，帮助 SRE 在曲线对账时快速定位根因：

3.4 指标采集与对账注意事项

为确保性能曲线对账的准确性，建议遵循以下采集规范：

• 统一采集代理： 所有环境使用相同版本的 Prometheus Node Exporter 或 cAdvisor，避免指标计算逻辑差异。
• 标准化标签： 在指标中注入 environment、release_version、container_name 等标签，便于 PromQL 进行多环境联合查询。
• 基线窗口对齐： 迁移前在生产环境采集至少 24 小时的基线数据，迁移后对比相同时间段（如工作日 10:00-11:00）的曲线。
• 异常值过滤： 在计算 P99 延迟和错误率时，排除已知的部署窗口、健康检查探针等非业务流量。

3.5 指标对账的典型流程

下图展示了从指标采集到曲线对账的完整流程，帮助 SRE 团队建立标准化的迁移验证步骤：

3.6 关键指标速查表

以下速查表供 SRE 在迁移对账时快速参考，包含每个指标的 PromQL 查询示例：