Zabbix 6.0 监控 vCenter 7.0这几个字背后其实是很多虚拟化运维的共同痛点虚拟机越开越多宿主机状态只能凭感觉存储动不动就满了出问题时才发现当初根本没留监控数据。装了 vCenter 7.0 之后系统自带的 vSphere Client 只是“管理工具”指望它 7x24 小时盯着所有对象不现实把 vCenter 里的数据统一收进 Zabbix才是把虚拟化平台真正纳入运维体系的开始。这篇内容是我实际做这个项目时的完整记录包含方案选型、账号权限、前端配置、数据验证、排障和调优适合正在维护 VMware 环境、又恰好选用了 Zabbix 的运维同学参考。1. 先想明白这套方案到底在监控什么1.1 不只是“看虚拟机通不通”很多人一提监控 vCenter第一反应是“虚拟机挂了能报警就行”。实际落地之后你会发现问题远不止这些。Zabbix 通过 vCenter 的 SDK 接口能拿到的数据几乎是 vCenter 控制台里能看到的全部我通常把它们分成四层vCenter 服务本身版本号、服务可用性、SDK 接口连通性。这一层最容易被忽略vCenter 要是挂了下面的虚拟机虽然短期还在跑但整个虚拟化平台已经失去管理能力属于重大故障。集群ClusterCPU 总容量与分配率、内存总容量与分配率、集群内主机数量、DRS/HA 状态。这个视角能回答“我现在的集群还能再塞多少虚拟机”这种问题。宿主机ESXi HostCPU 使用率、内存使用率、网络吞吐、存储 I/O 延迟、硬件健康状态、维护模式状态。宿主机故障或者进入维护模式直接影响所有跑在它上面的虚拟机。虚拟机VMCPU、内存、磁盘使用率网络流量磁盘读写延迟Guest Tools 状态运行状态。这是日常告警最密集的一层。除了这些还有数据存储Datastore的容量使用率、存储 I/O 延迟、快照数量等。可以这么说只要 vCenter 控制台里能看到的性能图表Zabbix 基本都能采到而且能叠加你自己的告警阈值和历史保留策略。1.2 vCenter 7.0 的部署变化对监控接口有什么影响vCenter 7.0 相比 6.x 最大的变化是彻底取消了 Platform Services ControllerPSC这个概念。在 6.x 时代很多公司部署了外部 PSC升级或者迁移时经常被 PSC 的依赖关系折磨。到了 7.0官方只提供 VCSAvCenter Server Appliance一体机部署方式安装部署流程比 6.x 简单很多这也是“vcenter7.0安装部署”检索热度高的原因——新版本确实值得从旧环境迁移过来。对监控来说这个变化影响不大但有一点要明确无论 vCenter 以什么形态部署Zabbix 接入时使用的 SDK 端点都是同一个即https://vcenter-address/sdk。这是 vCenter 对外暴露的 Web Services API 端点走的是 HTTPS SOAP 协议。Zabbix 就是靠这个端点完成认证、拉取对象清单和性能数据的。另外一个容易被忽略的点是 vCenter 7.0 的证书策略更严格了。7.0 默认强制使用 VMware Certificate AuthorityVMCA签发的证书很多环境的 vCenter 证书是自签名或者内部 CA 签发的。Zabbix 侧的 libcurl 在建立 HTTPS 连接时会校验证书链证书不可信就会握手失败这个问题我在第 2 章会专门讲处理办法。1.3 为什么选 Zabbix 6.0 而不是其他版本如果你已经在用 Zabbix 5.0 或者 5.4可能会问要不要为了监控 vCenter 特地升到 6.0。我的建议是只要条件允许直接上 6.0。原因有两个层面一是版本生命周期。Zabbix 6.0 是 LTS 版本官方支持周期很长适合作为生产环境的底座。二是 VMware 监控架构的差异。Zabbix 5.0 及以前的版本监控 VMware 的方式是 Zabbix Server 通过一个个独立的监控项键值去请求 vCenter每次请求都实时调用 vCenter 的 SDK 接口。环境小问题不大但一旦虚拟机数量上了 300、500这种“按需拉取”的模式性能非常差vCenter 的 SOAP 接口容易被拖垮Zabbix 自身的 polling 也会积压。Zabbix 6.0 改成了“VMware Collector 缓存”的模式。Zabbix Server 或者 Proxy 启动独立的 VMware collector 进程周期性地从 vCenter 拉取所有数据存到内存缓存里前端页面上的监控项请求都从缓存读不再实时打 vCenter 接口。性能提升是一眼能看出来的虚拟机数量很大时也不会把 vCenter 压垮。另外关于 license 问题Zabbix 是开源免费的监控接口本身也不会消耗 vCenter 的 license 名额这点可以完全放心。2. 动手前的重要准备账号、权限、连通性2.1 在 vCenter 里创建只读监控账号监控账号的第一个原则是权限能少给就少给。有的教材让你直接拿 administratorvsphere.local 去填 Zabbix这种做法很危险一旦 Zabbix 服务器被入侵等于直接把整个虚拟化平台的最高权限交出去了。正确的做法是创建一个专用监控账号只分配只读角色。操作路径登录 vSphere Client通过浏览器进入 vCenter 管理界面在左侧导航栏的“管理”里找到“用户和组”先添加一个用户例如zabbix-monitor设置一个符合密码复杂度要求的密码。然后在“管理”的“访问控制”里找到“全局权限”点击“”号添加权限选择刚才创建的用户角色选择“只读”勾选“传播到子对象”。这个“传播到子对象”非常重要不勾的话账号只能看到 vCenter 本身看不到下面的集群、宿主机和虚拟机Zabbix 自动发现出来的数据会是空的。创建账号之后一定要在 vCenter 上验证一下这个账号能正常登录 vSphere Client 并看到所有对象。有些环境做了精细权限拆分比如按业务部门分权这类环境下要特别注意监控账号是否对所有对象都有只读权限否则 Zabbix 采集数据会出现“部分对象拿不到”的情况排查起来比整体不可用更头疼。2.2 确认 Zabbix Server 或 Proxy 侧的 Collector 配置Zabbix 6.0 里负责连接 vCenter 的是 VMware collector 进程这个进程集成在 Zabbix Server 或 Zabbix Proxy 内部通过配置文件控制。如果你是小环境只有一台 Zabbix Server直接改/etc/zabbix/zabbix_server.conf里的这几个参数StartVMwareCollectors1 VMwareFrequency60 VMwareCacheSize16M VMwareTimeout20参数含义我简单解释一下StartVMwareCollectors启动的 VMware collector 进程数量默认是 1小于等于 0 表示禁用。一般先保持 1环境大了再调大。VMwareFrequencycollector 向 vCenter 拉取数据的频率默认 60 秒。这个不是越小越好拉取频率越高vCenter 的负载越大。VMwareCacheSizeVMware 数据在内存中的缓存大小默认 8M。虚拟机数量多时缓存被写满会导致采集数据被丢弃或覆盖所以环境大建议提到 16M 或 32M。VMwareTimeoutcollector 连接 vCenter 的超时时间单位是秒。有些首次采集时对象很多响应慢超时时间太短会导致采集失败我一般设置为 20。改完配置文件后必须重启 Zabbix Server 才能生效sudo systemctl restart zabbix-server如果用的是分布式架构vCenter 的监控任务跑在某个 Zabbix Proxy 上那这些参数要配置在对应的zabbix_proxy.conf里并重启该 Proxy而不是改 Server。腾讯云上看到的很多故障案例里常见原因是用户根本没开StartVMwareCollectors默认虽然是 1但有些从旧版本升级上来的环境配置文件里可能有StartVMwareCollectors0的遗留设置导致前端监控项全部显示“不支持”。这个细节我会在第 5 章排障部分再展开。2.3 vCenter 7.0 的 TLS 证书和时间同步问题很多人在配置完账号和 URL 之后发现 Zabbix 日志里出现 TLS 握手失败一类的问题这就是 vCenter 7.0 的证书策略在捣乱。先看周边条件vCenter 7.0 默认只启用 TLS 1.2不再支持 TLS 1.0 和 1.1。Zabbix 6.0 的编译环境如果比较新OpenSSL 和 libcurl 都支持 TLS 1.2问题不大。关键还是在证书链验证上。vCenter 默认使用 VMCA 签发的证书这个证书不是你浏览器里已经信任的那些公共 CA如 DigiCert、GlobalSign签发的所以 Zabbix 侧的 libcurl 在校验时会返回证书无法验证的报错。解决办法不是把 Zabbix 的证书校验关掉而是把 vCenter 的根证书加入 Zabbix Server 所在操作系统的信任区。在 CentOS/RHEL 系列系统上操作路径是通过浏览器访问https://vcenter-address/certs/download.zip下载 vCenter 的证书压缩包里面包含根证书和机器证书。把根证书文件通常是certs/lin/hash.0或者.crt格式复制到/etc/pki/ca-trust/source/anchors/目录下。执行sudo update-ca-trust extract更新系统证书链。重启 Zabbix Server 让 libcurl 重新读取 CA 证书。如果你的 Zabbix 是源码包编译安装的libcurl 可能没有使用系统默认的 CA 路径这时可以先在命令行里测试一下连通性curl -k -u zabbix-monitorvsphere.local:YourPassword https://vcenter.example.com/sdk去掉-k再执行一次如果返回证书错误说明系统 CA 还没完全生效。解决办法是在启动 Zabbix Server 前设置环境变量CURL_CA_BUNDLE/etc/pki/tls/certs/ca-bundle.crt或者在 systemd unit 文件里加入EnvironmentCURL_CA_BUNDLE...。时间同步是另一个经常被忽略的点。vCenter 的 SOAP 接口做认证时会校验客户端和服务端的时间偏差偏差过大直接认证失败。Zabbix Server 和 vCenter 都要配置 NTP 时间同步建议两个端都指向同一个时间源这样可以省去很多莫名其妙的问题。3. 前端配置实操从新建主机到看到第一份数据3.1 在 Zabbix 里新建 VMware 类型主机准备工作做完之后就可以在 Zabbix 前端操作了。整个配置的关键点在于监控 vCenter不要用普通的 Zabbix Agent 方式去建主机而是在创建主机时把“类型”选为“VMware”。具体步骤登录 Zabbix Web 界面进入“数据采集”→“主机”→“创建主机”。在“主机”选项卡里主机名称填一个方便识别的名字比如vCenter-7.0-Prod可见名可以写中文或业务名这个随你习惯。最重要的是“由代理监控”这一项如果 Zabbix Server 直接采集就选择“无代理”或留空如果走 Proxy 就选择对应的代理。然后“类型”必须选“VMware”不能选“Zabbix agent”。类型选好之后下方会弹出一组和 VMware 相关的字段IP 地址这里填 vCenter 的 IP 或域名。宏标签里 Zabbix 6.0 的官方模板默认会给出一组宏实际宏名取决于你导入的模板版本常见的有{$VMWARE.URL}、{$VMWARE.USERNAME}、{$VMWARE.PASSWORD}。有的升级环境里也可能保留老模板的下划线写法比如{$VMWARE_URL}。无论哪种你只需要关注前端页面上实际列出的宏名照着填就行。填完主机信息后在“模板”选项卡里搜索“VMware”关联官方自带的VMware模板。这个模板会启用 VMware 相关的自动发现规则和监控项是整个监控方案的核心。3.2 三个关键宏的填写与覆盖方式宏是 Zabbix 配置里最灵活的部分也是新手最常犯错误的地方。官方模板里给宏设了默认值但这些默认值不可能适配你的环境必须在主机级别覆盖。三个宏的正确写法是{$VMWARE.URL}填https://vcenter-address/sdk。注意这里结尾一定要带/sdk这是 Zabbix 连接 vCenter SDK 接口的标准路径。漏掉/sdk是最常见的错误之一填完保存后监控项长时间显示“不支持”日志里报Cannot connect to VMwareservice。{$VMWARE.USERNAME}填你在 vCenter 里创建的监控账号比如zabbix-monitorvsphere.local域名后缀不能漏。{$VMWARE.PASSWORD}填对应密码。如果走的是 Zabbix 加密的 secrets 管理可以填引用宏否则直接填明文即可Zabbix 前端会通过加密存储在数据库里一般场景够用了。宏填完之后还要检查一下“宏观”的生效范围。主机级别的宏会覆盖模板级别的同名校验宏所以只要在主机上填了模板默认值就不会干扰你的环境。有一个小技巧如果你有多个 vCenter 要监控不要一个个去填宏可以在主机创建后用 Zabbix 的“宏”页面批量添加或者直接复制主机创建第二台改一下名字和 URL 就行效率高很多。3.3 最快验证数据是否采集成功的方法配置保存后不要急着去配告警先确认数据是否真正采上来了。Zabbix 的 VMware collector 是周期运行的第一次连接 vCenter 并完成自动发现通常需要一到几分钟视 vCenter 规模而定。验证分为三步第一步看“监控项”列表。进入刚刚创建的主机点击“监控项”筛选 VMware 相关的监控项比如vmware.vm.count、vmware.hv.count、vmware.version。如果这些监控项的值不是“不支持”说明 collector 已经成功连接 vCenter 了。第二步看“发现的主机”。进入“数据采集”→“主机”你会看到除了刚才手动创建的 vCenter 主机之外多出了很多自动创建的主机这些就是模板的发现规则自动生成的“VMware Guest”、“VMware Hypervisor”、“VMware Datastore”、“VMware Cluster”等类型的虚拟主机。它们的命名通常来自发现规则中的宏比如源对象名称。如果这些自动主机出现了说明自动发现已经跑通。第三步看“最新数据”。随便点开一台自动发现的虚拟机查看它的 CPU、内存监控项是否有最近的数据。如果能看到数据说明整个链路彻底通了。我在实操中习惯用一条 curl 命令在服务器上先预判一下问题出在哪一层curl -s -u zabbix-monitorvsphere.local:YourPassword https://vcenter.example.com/sdk | head -c 500如果返回内容里有 SOAP XML 相关的关键字说明 vCenter 的 SDK 服务可达如果直接报连接拒绝或者证书错误就不用去 Zabbix 前端反复排查了。4. 数据进来之后看懂监控项、触发器与性能调优4.1 自动发现的逻辑与命名宏Zabbix 6.0 的 VMware 模板之所以能自动生成那么多主机靠的是自动发现规则。模板里的发现规则会定期从 vCenter 拉取所有对象列表按照对象类型虚拟机、宿主机、数据存储、集群分类然后根据发现规则里配置的宏和模板自动创建对应类型的主机并关联模板。这个机制带来的最大好处是以后你在 vCenter 里新建虚拟机Zabbix 会在下一轮自动发现时自动把它纳入监控不需要手动添加。同理虚拟机删除了Zabbix 里的自动主机也会在清理规则作用后被动消失。自动主机的命名是通过发现宏来实现的。举个例子虚拟机发现规则里常见的宏有{#VM.NAME}宿主机发现规则里有{#HV.NAME}数据存储发现规则里有{#DATASTORE.NAME}。在发现规则“创建主机”的配置项里主机名称会引用这些宏。如果模板默认的命名方式满足不了你比如你希望自动主机名带上业务标签可以通过调整发现规则里的主机名称模板来实现。这里有个特别注意的点自动发现出来的主机在 Zabbix 里是独立主机但它的“IP 地址”字段通常是空的因为 Zabbix 是通过 vCenter 的 API 拿数据不是直接连虚拟机网卡。所以不要给这些自动主机添加 Zabbix Agent 接口也不要在上面尝试配置 Agent 监控两者是两套完全独立的采集链路。4.2 关键监控项与内置触发器Zabbix 官方 VMware 模板已经内置了一批监控项和触发器覆盖了最核心的监控需求。我按对象类型挑了十几个真正用得上的监控项对象类型关键监控项作用宿主机vmware.hv.cpu.usageCPU 使用率判断宿主机是否过载宿主机vmware.hv.memory.used内存使用量结合可用量判断是否充足宿主机vmware.hv.health.state硬件健康状态故障磁盘、电源等会在这里反映虚拟机vmware.vm.cpu.usage虚拟机 CPU 使用率虚拟机vmware.vm.memory.used虚拟机内存使用量虚拟机vmware.vm.status虚拟机的运行状态和 Guest Tools 状态数据存储vmware.ds.size数据存储容量总量数据存储vmware.ds.free数据存储剩余空间集群vmware.cluster.status集群健康状态vCentervmware.versionvCenter 版本信息这些监控项里我最看重的是vmware.hv.health.state和vmware.vm.status。宿主机硬件故障不是每天发生但一旦发生就是严重故障靠人工巡检容易漏Guest Tools 状态异常往往意味着虚拟机内部有问题比如 VMware Tools 崩溃、系统时间异常等提前发现能避免后续备份、迁移时出问题。模板自带的触发器比如数据存储空间不足的告警默认阈值通常比较保守一般是容量使用率达到 80% 或 90% 才触发。实际使用中不要直接照搬需要结合自己环境的容量规划来调整。比如某些业务数据每天增量很大集群里数据存储 70% 使用率就已经很危险了因为留不下快照空间和重建时间这种场景就该把触发阈值改到 70%。我的习惯是给每个数据存储按业务重要性分优先级核心存储的告警阈值 75%非核心存储 90%避免告警风暴掩盖真问题。4.3 数据量大时的采集性能调优如果你的环境比较大虚拟机数量超过 1000或者一个 Zabbix 里管了好几个 vCenter就需要注意 VMware collector 的性能调优了。最直接的参数是增大StartVMwareCollectors。这个值不是随便调大的每个 collector 进程会独立处理一部分 vCenter 的采集任务。调大之前要先确认 Zabbix Server 宿主机配置一般 4 核 8G 的服务器上开 2~4 个 collector 是比较稳妥的。每个 collector 都会占内存VMwareCacheSize建议跟着调大比如 64M 或 128M。另一个思路是分端口采集。如果同时监控多个 vCenter可以考虑给每个 vCenter 单独配置一个 collector 组。Zabbix 6.0 支持在主机配置里指定使用哪个 collector你可以把不同 vCenter 的主机分别分配到不同的 collector这样能有效避免单个 collector 成为瓶颈。如果 Zabbix Server 本机性能已经吃紧更合理的方案是引入 Zabbix Proxy。让 Proxy 部署在离 vCenter 更近的网络位置vCenter 的采集任务全部由 Proxy 承担Server 只负责汇总和告警。这个架构改造虽然前期要多部署一个 Proxy但长期来看扩展性和稳定性都更好尤其适合跨数据中心、跨网段监控的场景。最后提醒一点vCenter 本身对 SOAP 接口的请求量是有限制的。Zabbix 的VMwareFrequency参数不要调太低60 秒已经足够低于 30 秒对大多数环境来说没有必要还会给 vCenter 增加无谓的负载。VMware 官方也建议第三方监控软件的轮询频率不要低于 20 秒。5. 常见问题排查我从实际环境里遇到过的情况5.1 数据采集全为 0 的排查路径监控配置好了但所有 VMware 监控项都是“不支持”或者“无数据”这是最多人遇到的问题。我建议按下面的顺序排查而不是盲目重启服务。第一步先看 Zabbix Server 的日志。日志路径通常是/var/log/zabbix/zabbix_server.log搜索关键词vmware。如果你看到类似Cannot connect to VMware: Cannot get data from VMware service的报错基本可以确定是连接层面出了问题继续下一步。第二步测试 vCenter 地址的连通性。在 Zabbix Server 上执行curl -k -u zabbix-monitorvsphere.local:YourPassword https://vcenter.example.com/sdk如果返回Could not resolve host看 DNS 解析如果返回Connection refused或超时看防火墙和网络策略如果返回证书错误按第 2 章的证书处理流程走如果返回了 SOAP 相关的 XML说明网络层和 SDK 服务都是通的问题可能在账号或 URL 配置上。第三步检查 URL 结尾是否带/sdk。这个错误太典型了很多人填 URL 时习惯只填https://vcenter.example.comZabbix 会直接报连接失败因为/sdk才是 SOAP 服务的真实端点。第四步确认StartVMwareCollectors参数不是 0。这个参数在配置文件的默认值是 1但很多从老版本升级上来的环境可能存在手动改过的情况。如果日志里根本没有任何 vmware 相关输出优先怀疑 collector 没启动。5.2 权限和 URL 引发的典型报错速查表我在多个项目中踩过不少坑下面这张表是我整理的常用报错定位对照报错信息可能原因解决建议Cannot get VMware service data: (401)账号密码错误或账号被禁用在 vCenter 里重新验证账号能否登录Cannot get VMware service data: (403)账号没有权限或权限未传播重新分配“只读”角色并勾选传播到子对象Cannot get VMware service data: (500)vCenter 服务异常或版本不兼容登录 vCenter 查看服务状态确认 vCenter 7.0 和 Zabbix 6.0 兼容Cannot connect to VMware: Cannot get data from VMware serviceURL 未带 /sdk、网络不通、collector 未启动按 5.1 步骤排查Peer certificate cannot be authenticated with given CA certificatesvCenter 证书不被信任将 vCenter 根证书加入系统信任区监控项全部“不支持”且日志无 vmware 记录StartVMwareCollectors0修改配置并重启 Zabbix Server5.3 数据量大的时候 Collector 卡死与恢复策略虚拟机数量超过 2000 之后如果老版本遗留下来未调整配置VMware collector 偶尔会出现“假死”监控项数据不更新日志里大量超时重启 Zabbix Server 能恢复但过一段时间又不行了。这种情况通常不是 Zabbix 本身的 bug而是资源不够了。排查思路是先看VMwareCacheSize是否足够虚拟机太多、性能数据量太大时缓存会被写满写满后新的采集数据就只能丢弃监控项自然就不更新。把缓存调到 64M 或 128M重启服务观察一两天。如果缓存调大后仍然超时看VMwareTimeout是否太小。VMware collector 拉取性能数据时如果 vCenter 响应慢超过超时时间就会失败。把VMwareTimeout调到 30~60 秒能缓解大部分超时问题。再到 vCenter 侧确认一下是不是有其它监控工具也在疯狂轮询 vCenter导致 vCenter 的 SOAP 接口响应变慢。如果有协调错峰采集。最后一步才是增加StartVMwareCollectors。需要说明的是collector 数量增加会成倍占用内存建议结合free -h观察内存余量不要盲目加到很高不然可能引发 OOM。5.4 vCenter 从 6.x 升级到 7.0 后 Zabbix 的适配很多人是在 vCenter 6.5/6.7 时代已经把 Zabbix 监控配通了后来升级到 7.0 才发现监控出问题。升级过程中最容易踩的坑是证书变化。vCenter 升级后VMCA 会重新签发证书Zabbix Server 上缓存的旧证书就失效了。如果升级后 Zabbix 日志出现证书相关报错重新下载新证书、更新系统信任区即可。另一个坑是账号权限在升级后可能发生变化。vCenter 大版本升级时局部权限模型会有细微调整之前能正常采集的账号升级后可能只返回部分数据。这种问题最隐蔽因为不是完全连不上而是“少了一部分对象”。排查时先看自动发现出来的主机数量和升级前是否一致少了就回 vCenter 重新确认账号权限。vCenter 7.0 的 URL 端点没有变化不需要因为升级而修改 Zabbix 里的{$VMWARE.URL}。如果你升级之后 URL 填写的还是老地址但只要这个地址能解析到新的 vCenter就没问题。如果升级过程中 vCenter 的 IP 或主机名发生了变更记得同步修改 Zabbix 主机配置和宏。6. 一点真实使用体会项目做完之后这套监控方案已经稳定跑了半年多跨越了 vCenter 7.0 的两个补丁版本Zabbix 侧没有因为 VMware 监控本身产生过一次故障。最直观的感受是以前查虚拟机性能要去 vCenter 控制台点好几层菜单现在直接在 Zabbix 的仪表盘上一屏看全以前数据存储空间告警靠人工盯现在阈值一设快满的时候自动通知到对应责任人存储扩容的响应速度快了很多。如果让我给后来者一个建议那就是先用官方模板把数据采起来再花时间去调触发器阈值和命名规范不要一上来就想着定制各种骚操作。采集链路是基础基础通了后面的页面优化、告警策略、报表脚本都是水到渠成的事。文章最后分享一个实用的小技巧在 Zabbix 中给 vCenter 主机创建仪表盘时可以用“最新数据”组件把vmware.ds.free按剩余空间排序展示这样每天上班扫一眼哪个数据存储快满了清清楚楚比邮件告警还要直观。这是我自己用得最顺手的视图方案希望能帮到你。