1. 课程导入与性能监控全景
在生产环境中运行 vSphere，性能问题往往不是“有没有监控”的问题，而是“监控得对不对、看得懂不懂、改得准不准”的问题。一台 ESXi 主机上可能同时运行几十台虚拟机，CPU 就绪时间、内存气球回收、存储队列深度、网络丢包这些指标彼此耦合，任何一个环节出现瓶颈，都会以“业务变慢”的形式暴露出来。本课程的目标，是建立一套从指标采集、瓶颈定位到资源优化的完整方法，而不是停留在“打开 vCenter 看几个百分比”的层面。
性能监控要回答的三个问题
生产性能监控的本质，是持续回答三个问题：资源够不够用、谁在消耗资源、瓶颈在哪里。第一个问题关注容量与余量，例如集群整体 CPU 使用率长期高于 70%、内存余量不足 15%，就属于容量风险；第二个问题关注归属，需要把负载定位到具体虚拟机、资源池或数据存储；第三个问题关注根因，例如虚拟机 CPU 就绪时间高，可能是物理 CPU 争用，也可能是 vCPU 数量过多导致协同调度开销。三者层层递进，缺一不可。
需要特别强调的是，vSphere 中的“使用率”并不等于“压力”。CPU 使用率 90% 未必是问题，只要就绪时间接近 0；而 CPU 使用率 40% 也可能存在严重争用，因为多个虚拟机在等待物理核心。因此监控必须同时看利用率类指标和饱和度类指标，这是贯穿全课程的核心判断原则。
四大关键指标维度
CPU 维度：核心指标包括主机 CPU 使用率、虚拟机 CPU 就绪时间（Ready）、协同停止时间（Co-Stop）、CPU 争用（Contention）。就绪时间表示虚拟机已就绪但物理 CPU 不可用的等待比例，持续超过 5% 通常意味着 CPU 资源紧张或 vCPU 配置过大。
内存维度：关注主机内存使用率、虚拟机内存气球（Balloon）、交换（Swap）、压缩（Compression）以及内存回收。气球增长说明主机在向虚拟机“借”内存，Swap 出现则说明已进入严重过载，性能会断崖式下降。
存储维度：关注数据存储延迟（DAVG/CMDS 命令延迟）、队列深度、IOPS、吞吐量。虚拟机磁盘延迟持续高于 20ms 通常可感知，高于 50ms 则业务明显受影响。存储问题往往表现为“CPU 不高但业务卡”，需要结合延迟而非仅看 IOPS。
网络维度：关注物理网卡吞吐、丢包率、虚拟机网卡丢包与错误计数。丢包会触发 TCP 重传，表现为吞吐下降而链路利用率不高，容易被误判为应用问题。
监控工具链的分工
vSphere 生产监控通常由三层工具协同完成。vCenter 提供集中式、历史化的性能图表与告警，适合趋势观察和容量评估，但采样粒度较粗（默认 20 秒，历史数据按级别降采样）。esxtop 运行在 ESXi 主机上，提供秒级实时视图，能直接看到就绪时间、气球、队列深度等底层指标，是定位瞬时瓶颈的利器。vRealize Operations（现为 Aria Operations）在两者之上做关联分析与容量预测，通过“异常—症状—根因”模型把指标转化为可操作的建议。
三者的关系可以概括为：vCenter 看趋势，esxtop 看现场，vRealize Operations 看关联与预测。实际排障时，通常先用 vCenter 或 vRealize Operations 发现异常，再登录主机用 esxtop 确认现场，最后回到 vCenter 调整配置并验证。
资源优化闭环
监控的终点不是“看到问题”，而是“解决问题并确认有效”。完整的优化闭环包含四个环节：采集——按统一口径收集主机、虚拟机、存储、网络指标并建立性能基线；分析——结合利用率与饱和度指标定位瓶颈层级；优化——调整 vCPU 数量、内存分配、资源池份额、存储策略或网络队列；验证——在相同业务负载下对比优化前后的关键指标，确认改善且未引入新问题。
这个闭环的关键在于“验证”环节常被忽略。例如把某虚拟机 vCPU 从 8 降到 4，如果只看 CPU 使用率下降就认为成功，可能忽略了业务吞吐是否同步下降。正确的做法是对比优化前后的就绪时间、业务响应时间和吞吐量，确认在满足业务的前提下资源占用下降，才算真正完成优化。