2026 年 VMware 监控指南：工具、指标与性能

大多数 VMware 环境看起来一切正常——直到出问题为止。一台主机无响应、一个数据存储空间用尽，或者 VM 性能在数天内悄然下降，却无人察觉。

良好的 VMware 监控能够在这些问题演变为事故之前发现它们。本指南涵盖需要跟踪的关键指标、如何设置实用的监控工作流，以及 2026 年最适合 vSphere 环境的工具。

什么是 VMware 监控以及它为何重要

VMware 监控是持续跟踪 ESXi 主机、vCenter Server 以及运行您应用程序的虚拟机的过程。

在共享的虚拟化环境中，问题不会孤立存在。单个过载的 VM 可能拖垮整个主机，而一个逐渐填满的数据存储可能同时导致多个工作负载离线。监控让您能够在这些问题升级之前发现它们。

自 Broadcom 收购以来，风险更高了。许多组织现在面临更高的许可成本和更大的资源优化压力。

基于这些原因，VMware 监控变得比以往任何时候都更加重要。它不仅仅是一个最佳实践，更是维护 VMware 环境性能、可用性和成本效率的关键组成部分。

如何监控 VMware：分步方法

构建一个坚实的监控框架需要分层策略。单一的指标无法告诉你一个分布式系统的完整健康状况。你需要将虚拟机管理程序级别的数据与每个 VM 内部实际发生的情况结合起来。

1. 从原生工具开始

vSphere Client 性能图表是您的起点。无需额外软件。导航到任何 VM 或主机，选择 监控 > 性能 > 高级 以访问实时和历史数据。

这些图表允许您同时比较最多三个指标，并在堆叠视图和叠加视图之间切换——这对于发现相关性（如 CPU 峰值与存储延迟上升相关）非常有用。

2. 增加客户机操作系统可见性

VMware API 在虚拟机管理程序级别提供了强大的可见性，但它无法看到 VM 内部。为了获得完整的图景，请将虚拟机管理程序指标与客户机操作系统数据配对。

对 Windows 服务器使用 WMI，对 Linux 主机使用 SNMP 或 SSH。这让您可以比较虚拟机管理程序报告的内容与应用程序在客户机操作系统内部实际体验到的内容。

3. 设置性能基线

静态阈值可能具有误导性。90% 的 CPU 峰值对于 SQL 服务器在备份窗口期间可能是正常的，但对于 Web 网关来说却是一个危险信号。

在可能的情况下，使用具有 AI 或 ML 能力的工具来了解每个工作负载的“正常”状态。这可以减少误报，并帮助仅浮现真正需要关注的告警。

4. 配置关键告警

基线设置好后，为已知的性能问题设置告警。大多数管理员从以下阈值开始：

• CPU 就绪时间： 如果超过 5% 则告警。
• 内存膨胀： 如果膨胀驱动程序处于活动状态则告警——这表示主机内存超分配。
• 数据存储容量： 在 80% 时设置警告，在 85% 时设置严重告警，以避免可能导致 VM 崩溃的空间不足错误。

5. 构建统一仪表板

避免在工具和标签页之间不断切换。一个聚合了跨主机、VM 和数据存储数据的单一仪表板，让您更容易发现集群范围的模式——例如整个集群的延迟升高——这是单个 VM 视图会错过的。

如果您管理 VDI 工作负载，请在仪表板中包含一个 VMware Horizon 监控部分。将会话连接成功率与主机健康状态一起跟踪，帮助您快速区分网络问题和服务器问题。

6. 自动化修复

对于大多数生产事故来说，手动响应太慢了。成熟监控设置的最后一步是将告警连接到自动化操作——无论是在您的 ITSM 平台中创建工单，还是触发 PowerCLI 脚本以添加存储或通过 vMotion 移动有问题的 VM。

需要跟踪的关键 VMware 性能监控指标

一个健康的 vSphere 环境需要的不仅仅是检查主机是否在线。高效团队会跟踪特定指标，这些指标揭示了虚拟机管理程序管理共享资源的效率。

CPU 指标

在虚拟化环境中，CPU 性能不仅仅是关于利用率百分比。更重要的问题是 VM 是否在需要运行时得到了调度。

• CPU 利用率与 CPU 就绪时间： 利用率显示消耗了多少处理能力。CPU 就绪时间显示 VM 等待 ESXi 主机在物理核心上调度它的时间。在这两者中，CPU 就绪时间是争用更具可操作性的指标。
• 5% 规则： VMware 建议在 CPU 就绪时间超过 5% 时发出告警。这通常指向高争用或分配给单个 VM 的 vCPU 过多。
• CPU 超分配比率： 这是虚拟 CPU 与物理核心的比率。4:1 的比率通常被认为是安全的，但在扩展时监控这一点可以帮助您在资源耗尽成为问题之前发现它。

内存指标

vSphere 使用多种技术从空闲 VM 回收 RAM，这使得内存监控比物理服务器更细致入微。

• 已消耗内存与活动内存： 已消耗内存是 VM 曾经接触过的总 RAM；活动内存是它当前实际使用的内存。两者之间的巨大差距通常意味着 VM 规模过大。
• 内存膨胀和交换： 如果膨胀驱动程序 (vmmemctl) 处于活动状态，则 ESXi 主机的物理 RAM 不足，正在从 VM 回收内存。如果主机开始将内存交换到磁盘，性能会急剧下降。
• 已授予、已预留和开销内存： 跟踪这些指标以确保您最关键的工作负载拥有在负载下保持稳定所需的预留内存。

磁盘和存储指标

存储是虚拟化环境中最常见的性能瓶颈之一。跟踪吞吐量和等待时间。

• 磁盘 I/O 延迟： 以毫秒为单位测量。VMware 的一般指导是将总延迟 (GAVG) 保持在 20ms 以下。持续高于该水平的读数通常会导致明显的应用程序减速。
• IOPS 和吞吐量： 同时跟踪每秒操作数和传输的数据量 (MB/秒)，以全面了解存储负载。
• 数据存储容量： 监控存储增长趋势，防止快照悄然消耗可用空间并填满您的数据存储。

网络指标

虚拟网络流量可能难以排查，因为其中大部分流量从未离开物理主机。

• 丢包： vSwitch 或端口组上的高丢包计数是网络拥塞或 MTU 设置错误的明确信号。
• 利用率和吞吐量： 带宽使用情况和吞吐量共同显示哪些 VM 可能正在饱和其虚拟网卡并导致更广泛的网络性能下降。

主机和集群健康状态

在集群级别，您需要了解资源如何平衡以及您的容错机制是否按预期工作。

• HA 和 DRS 活动： 频繁的 vMotion 事件可能表明 DRS 正在加班加点，以补偿平衡不佳或资源不足的集群。
• ESXi 主机正常运行时间和硬件传感器： 跟踪连接状态和物理健康指标，如电源和风扇状态。及早发现硬件问题可以防止计划外的 HA 故障转移事件。

快速参考：指标阈值

这些阈值被广泛用作起点，但正确的值将根据您的工作负载和存储类型而变化。

如何选择合适的 VMware 监控工具

合适的监控工具取决于您的团队规模、技术专长和预算。一些组织从原生 vSphere 工具中获得所需的一切。其他组织则需要第三方平台来获得对 ESXi 主机或混合云环境的更深入可见性。

原生 VMware 工具

大多数管理员从其 vSphere 许可证附带的工具开始。

• vSphere Client： 每个 vSphere 管理员的内置界面。它适用于实时故障排除和基本性能趋势，但长期数据保留有限，且没有跨集群分析。
• VMware Aria Operations（前身为 vRealize Operations）： 专为大规模环境设计。它增加了预测分析、自动修复以及在资源问题导致停机之前识别它们的能力。

第三方 VMware 监控工具

第三方工具通常提供与非 VMware 基础设施（如物理存储阵列或公有云平台）的更广泛集成，并且通常提供更灵活的仪表板和告警选项。

如何选择：

三个因素通常决定哪个工具合适：

• 环境规模： 对于较小的部署，原生 vSphere 工具可能就足够了。随着您的环境在多个站点和集群中增长，您将需要一个能够大规模提供集中可见性的平台。
• 预算： 每个额外的软件订阅都会增加运行 VMware 的成本。许多团队寻找能够覆盖其更广泛 IT 基础设施而不仅仅是 VMware 的工具，这有助于整合监控成本。
• 数据粒度： 如果您正在排查间歇性性能峰值，请寻找以短间隔轮询的工具。每几分钟收集一次数据的解决方案很容易错过短暂但影响巨大的活动突发。

VMware 监控最佳实践

正确的工具只能带你走这么远。您如何配置和维护监控策略决定了您是能及早发现问题，还是事后花时间解释宕机原因。

持续监控，而非定期监控

一个显著的性能峰值可能在 60 秒内发生并消失。如果您的监控工具每五分钟轮询一次，该事件将永远不会出现在您的数据中——让您无法在事后解释用户投诉。

大多数现代监控工具提供 30 秒的轮询间隔。如果您的工具没有，请考虑它是否能跟上生产 vSphere 环境的需求。

在设置阈值之前建立基线

开箱即用的告警阈值很少对您的特定工作负载准确。域控制器和视频渲染服务器具有截然不同的正常 CPU 配置文件。

在配置自定义阈值之前，观察每个工作负载至少两周。这可以减少误报，并确保告警反映实际的应用程序行为，而不是通用默认值。

使用告警层级减少告警疲劳

并非每个问题都需要立即响应。两层系统帮助您的团队确定优先级：

• 警告： 应在工作时间内审查的情况，例如数据存储达到 75% 容量，或非关键 VM 接近 CPU 就绪阈值。
• 严重： 需要立即采取行动的情况，例如主机断开连接、生产服务器将内存交换到磁盘，或数据存储超过 90% 容量。

定期审计资源蔓延

已开机但不再活跃使用的 VM 会消耗 CPU、内存和存储——在基于订阅的许可模式下，它们还可能增加您的成本。

定期检查您的 vCenter 清单，查找在 30 天窗口内 CPU 利用率接近零且没有磁盘活动的 VM。停用未使用的工作负载可以释放资源，并可能减少您的许可占用空间。

及时了解许可变更

一些第三方监控工具按插槽数或 VM 数定价。当您扩展或整合环境时，请确保您的监控成本不会比您的基础设施增长得更快。

审查 Broadcom 持续的许可更新如何影响您的 VMware 堆栈以及其上的第三方工具。

监控还不够：备份您的 VMware 环境

监控告诉您什么时候出了问题。它无法在数据丢失后恢复您的数据。

许多 IT 团队在可见性工具上投入巨资，却将备份视为事后考虑。这是一个危险的缺口。在 VMware 环境中，真正的备份策略需要您的数据有一个独立的、单独的副本，无论生产环境发生什么，都可以恢复。

这就是专用备份解决方案变得必不可少的地方。i2Backup 是一个企业备份平台，旨在保护 VMware 环境以及物理服务器、数据库和非结构化数据——全部通过一个管理控制台完成。

i2Backup 的关键特性

• 无代理 VM 备份： i2Backup 使用原生虚拟化平台 API 备份 VM，无需在客户机操作系统上安装代理。这意味着备份任务期间对生产工作负载零影响——这是高密度 VMware 环境的关键要求。
• 即时 VM 恢复： 在主机发生故障时，i2Backup 可以将 VM 备份远程挂载到目标平台，实现超低恢复时间，无需等待完整恢复完成。
• 文件级和时间点恢复： 并非每个恢复场景都需要恢复整个 VM。i2Backup 允许您从任何恢复点检索特定文件、文件夹或数据库条目，使用连续备份日志将数据恢复到确切的时间点。
• 灵活的计划和智能清理： 备份计划可以配置为每小时、每天或按自定义节奏运行。保留策略自动删除过时的备份，无需人工干预即可控制存储使用量。
• 集中管理： 基于 Web 的控制台提供对备份任务状态的实时可见性，并通过电子邮件和短信告警让您的团队了解情况，无需登录多个系统。

对于需要不仅仅是备份的团队，英方软件还提供 i2Availability，这是一个高可用性解决方案，为 VMware 和其他虚拟化环境提供实时复制和自动故障转移，帮助您在生产故障发生时最小化 RPO 和 RTO。

监控和备份作为一对组合效果最佳。监控为您提供早期预警；备份为您提供恢复路径。它们共同构成了弹性 VMware 环境的基础。

结论

有效的 VMware 监控不是一次性的设置。它是一个持续的过程，需要正确的指标、正确的工具以及随环境增长而发展的策略。

从基础知识开始：跨 ESXi 主机和 VM 跟踪 CPU 就绪时间、内存压力、存储延迟和网络健康状况。在设置阈值之前建立基线，使用告警层级减少噪音，并定期审计资源蔓延，这些资源会悄悄增加您的成本。

随着您的环境扩展或许可情况演变，重新审视您的工具。适用于 10 主机集群的方案可能不足以应对具有混合云扩展的多站点部署。

请记住：监控告诉您什么时候出了问题，但它无法恢复已经丢失的数据。将可靠的监控策略与可靠的备份解决方案（如英方软件的 i2Backup）配对，确保可见性和可恢复性协同工作，而不是孤立运行。