1. 课程导入与监控告警容量运营全景
在虚拟化平台的日常运维中，vSphere 的稳定性从来不是靠"出事再修"来保证的。真正让平台长期平稳运行的，是一套围绕监控、告警、容量运营三条主线建立起来的持续运营机制。本课程的目标，就是把这套机制从概念讲清楚，再落到可执行的对象、参数、判断依据和操作过程上，让读者能够独立搭建并维护一套属于自己的 vSphere 运营体系。
一、为什么要做监控告警与容量运营
很多团队对 vSphere 的管理停留在"能开机、能迁移、能扩容"的层面，直到某天出现以下场景：某台 ESXi 主机内存使用率长期在 92% 以上，一次 HA 切换后剩余主机无法承载全部虚拟机；某个数据存储的剩余空间在两周内从 40% 掉到 3%，导致虚拟机快照无法合并；某台虚拟机的 CPU 就绪时间（Ready Time）持续偏高，业务方投诉"系统卡"，但运维查不到明确原因。这些问题的共同点是：故障发生前其实早有信号，只是没有人把它变成可观测、可判断、可行动的指标。
监控解决"看得见"的问题，告警解决"及时知道"的问题，容量运营解决"提前准备"的问题。三者不是并列的三件事，而是一条从数据采集到决策执行的链路：监控产生指标，指标触发告警，告警与趋势数据共同支撑容量判断，容量判断又反过来决定监控阈值和告警策略是否需要调整。
二、监控、告警、容量运营的边界与对象
要建立全景认知，先要明确每一层管什么、不管什么。
监控的对象是 vSphere 的物理与逻辑资源，主要包括：ESXi 主机的 CPU、内存、存储、网络四大资源；vCenter Server 自身的服务状态与数据库健康度；集群的 HA/DRS 状态；数据存储（VMFS、NFS、vSAN）的容量与延迟；虚拟机的资源使用与性能计数器。监控的边界是"采集与呈现"，它回答"现在是什么状态"。
告警的对象是监控指标中那些越过阈值的异常状态。告警的边界是"判断与通知"，它回答"哪些状态需要人介入"。告警不等于故障，它是对偏离正常基线的提示，因此阈值设定、告警级别、抑制与聚合策略都属于告警范畴。
容量运营的对象是资源的使用趋势与剩余承载能力。它的边界是"预测与规划"，回答"还能撑多久、什么时候需要扩容、扩多少"。容量运营依赖监控提供的历史数据，但不直接处理实时告警。
三、角色分工
在中小规模环境中，这些角色往往由同一批人承担，但职责边界仍需分清，否则容易出现"告警没人认领"或"容量没人负责"的情况。
- 平台运维工程师：负责 vCenter、ESXi、集群的日常监控配置，处理主机级与集群级告警，执行扩容与迁移操作。
- 存储/网络管理员：负责数据存储与网络链路的容量和性能，处理存储延迟、链路饱和类告警。
- 容量规划负责人：定期汇总资源趋势，输出扩容建议与预算依据，维护容量基线。
- 业务方/应用负责人：提供业务增长预期，确认资源优先级，参与扩容窗口的协调。
四、整体工作流
把上述对象和角色串起来，就形成了一条闭环工作流：采集指标 → 建立基线 → 设定阈值与告警 → 接收与分派告警 → 处理与恢复 → 汇总趋势 → 容量评估 → 扩容或优化 → 调整监控策略。这条链路的关键在于"闭环"：如果只做前四步，就是被动救火；只有把趋势汇总和容量评估接上，才进入主动运营。
下面这张图展示了这条工作流中各环节的输入、输出以及它们之间的依赖关系，同时标出了每个环节的主要责任角色，便于在实际环境中对照分工。
五、一个可落地的起点
面对这套体系，初学者最容易犯的错是"一上来就配一堆告警"。更合理的起点是先做三件事：第一，确认 vCenter 与所有 ESXi 主机的监控数据能正常采集，检查 vCenter 的统计级别设置（建议至少为 2 级，即每 5 分钟采集一次）；第二，选定 3～5 个最关键的对象——通常是集群 CPU、集群内存、根数据存储容量、vCenter 服务状态——先为它们建立基线；第三，为这些对象设定第一版阈值，并明确每条告警由谁负责。
以集群内存为例，假设一个由 4 台主机组成的集群，每台主机 512 GB 内存，集群总内存 2048 GB，当前已分配 1500 GB，实际使用 1200 GB。如果按"已分配/总容量"计算，分配率约 73%；按"实际使用/总容量"计算，使用率约 59%。这两个数字含义不同：分配率反映的是"承诺出去多少"，使用率反映的是"真正消耗多少"。容量运营要同时看这两个值，因为分配率过高意味着 HA 切换时剩余主机可能无法承载，使用率过高则意味着真实资源紧张。假设近 30 天实际使用量从 1050 GB 增长到 1200 GB，日均增长约 5 GB，那么按当前趋势，距离 2048 GB 的 85% 水位（约 1740 GB）还有约 108 天。这个"剩余可用天数"就是容量评估的核心输出，也是决定何时启动扩容的依据。