Мониторинг VMware vCenter и ESXi на Zabbix 7.0 LTS: штатные шаблоны без скриптов

Мониторинг VMware Zabbix 7.0 LTS собирается двумя штатными шаблонами — «VMware» для vCenter и «VMware Hypervisor» для отдельных ESXi — без единого внешнего скрипта: сервер сам ходит в SOAP API vSphere через vmware collector. Это снимает главную боль старых связок вроде «Nagios + check_esx3.pl», которые ломались на каждой обновке ESXi.

Разбираем на практике: что шаблоны собирают из коробки, как завести read-only пользователя в vCenter, настроить StartVMwareCollectors и VMwareCacheSize под крупный кластер, какие триггеры ставить на снапшоты и датасторы, и что делать, когда метрики не идут.

Мониторинг VMware Zabbix в версии 7.0 LTS закрывается двумя штатными шаблонами — «VMware» для vCenter и «VMware Hypervisor» для отдельных ESXi — без единого внешнего скрипта, powercli-обёртки или самописного чекера. В официальной документации Zabbix для этой связки выделена отдельная глава «VMware template operation», где описаны все правила LLD и наборы элементов, которые сервер собирает через SOAP API vSphere. Мы на своих проектах перевели все инсталляции с самописных скриптов на эти шаблоны ещё в ветке 6.0 — с приходом 7.0 LTS решение окончательно стало «дефолтом на пятилетку».

Что закрывают штатные шаблоны без доработки: инвентаризация кластера, состояние ESXi-хостов, датасторы, дисковое пространство, виртуальные машины с их uptime, гостевой ОС, снапшотами, толстыми/тонкими дисками, счётчиками производительности CPU/RAM/сети. Отдельно собираются события vCenter — их удобно ловить триггерами по регуляркам. Ключи Simple check для VMware позволяют быстро добавить свои метрики поверх LLD, если нужен конкретный счётчик, которого нет в базовом наборе.

Раньше в проде мы часто видели связку «Nagios + check_esx3.pl + костыли на bash», которая падала на каждой второй обновке ESXi. Zabbix решает эту боль за счёт собственного vmware collector — отдельного процесса Zabbix-сервера, который кэширует данные vSphere в памяти и раздаёт их всем поллерам. По нашему опыту это единственный правильный способ собирать метрики VMware: обращаться к vCenter напрямую из скриптов на каждый чек — гарантированный способ упереться в лимиты API и получить в логах vCenter warning про «session count».

Мы не советуем изобретать велосипед даже там, где кажется, что штатный шаблон «неудобный». Практически всегда достаточно клонировать «VMware» в свою библиотеку шаблонов, отключить лишние LLD и добавить нужные триггеры — код трогать не нужно. Если чего-то реально не хватает, официальный quickstart-гайд по мониторингу VMware даёт готовые примеры расширения через ключи vmware.*.

Требования для мониторинга VMware Zabbix минимальны, но параметры StartPollers и VMwareCacheSize мы всегда правим до первого подключения vCenter — на дефолтах крупный кластер не собирается. Zabbix 7.0 LTS должен быть скомпилирован с флагом --with-openssl и опцией --with-libxml2 — это делает штатная сборка из пакетов zabbix.com. В официальном quickstart-гайде по VMware отдельно сказано, что для сбора метрик нужен активный vmware collector, а не Zabbix-агент — это принципиальный момент, который мы регулярно объясняем администраторам, привыкшим к агентному мониторингу.

Со стороны vCenter требуется HTTPS-доступ к API vSphere с Zabbix-сервера или прокси. На наших проектах мы всегда открываем сетевой доступ только с IP прокси и запрещаем прямое обращение к vCenter из общей сети мониторинга — так проще расследовать инциденты в аудит-логах vSphere. В zabbix_server.conf обязательно поднимаем StartVMwareCollectors — без ненулевого значения этого параметра ключи vmware.* не будут возвращать данные вообще. Начинайте с числа, сопоставимого с количеством vCenter’ов плюс запас на один-два поллера.

Параметр VMwareCacheSize — второе, что мы правим. Дефолт рассчитан на демо-стенд из пары ВМ. На кластере из нескольких сотен виртуальных машин кэш быстро упирается в потолок, в логе Zabbix-сервера появляются сообщения «VMwareCache is full», и часть LLD-правил не отрабатывает. Мы поднимаем размер поэтапно, ориентируясь на график vmware.buffer и общий рост памяти процесса zabbix_server.

Дополнительно проверяем Timeout и VMwareFrequency. По нашему опыту стандартного таймаута хватает для vCenter в локальной сети, но при работе через VPN до площадки заказчика мы поднимаем его выше — иначе половина LLD-правил падает по превышению времени ответа. Частоту опроса vSphere не имеет смысла делать слишком высокой: vCenter сам агрегирует часть счётчиков с шагом в несколько десятков секунд, чаще API отдавать не будет.

Проверить, что все эти параметры выставлены в конфиге, и применить изменения можно прямо на сервере:

Мониторинг VMware Zabbix штатным шаблоном требует в vCenter отдельного пользователя с ролью Read-only — не администратора и не сервисной учётки, у которой права наследуются как попало. Мы всегда заводим доменную или локальную учётку прямо в vsphere.local, вешаем её на корень инвентаря vCenter и назначаем встроенную роль Read-only с флагом «Propagate to children». Прав этой роли достаточно для чтения инвентаря, состояния хостов, датасторов, ВМ, снапшотов и счётчиков производительности — именно того набора, который использует шаблон «VMware».

Почему не «Administrator» и почему не «сервисный аккаунт с полными правами». На одном из проектов заказчик изначально дал Zabbix root-права в vCenter «чтобы не разбираться». Через месяц админ vSphere по ошибке подставил эти же учётные данные в скрипт очистки старых снапшотов — и мы полдня восстанавливали продовую ВМ. Read-only-права физически не дают Zabbix ничего удалить или изменить в инфраструктуре, даже если конфигурация будет скомпрометирована. Это единственно безопасный режим для мониторинга.

Порядок наших действий в vSphere Client:

1. Заводим пользователя zabbix-monitor в домене SSO или локально в vsphere.local.
2. В корне vCenter → Permissions → Add. Указываем пользователя, роль Read-only, ставим галку Propagate to children.
3. Для отдельных сегментов инвентаря (DRS-кластер, отдельная папка ВМ, dvSwitch) проверяем, что права дошли — иногда наследование выключено на уровне папки, и метрики этой ветки просто не появляются в LLD.

Если vCenter в связке с NSX, vSAN или vROps — читаем их документацию отдельно: часть счётчиков производительности vSAN недоступна для чистой роли Read-only и требует отдельного разрешения. По нашему опыту в 90% инсталляций read-only на корень инвентаря закрывает всё, что нужно шаблону.

Не делайте так: не переиспользуйте учётку, под которой у вас работает Veeam или другой продукт резервного копирования. Мы видели, как совместный пароль ротировали в одном месте и забывали в другом — Zabbix молча переставал собирать метрики, а инженеры узнавали об этом только когда «внезапно» пропадали графики в отчёте руководству.

vCenter подключается к мониторингу VMware Zabbix через привязку шаблона «VMware» к хосту и три обязательных макроса — {$VMWARE.URL}, {$VMWARE.USERNAME} и {$VMWARE.PASSWORD}. В {$VMWARE.URL} записывается полный путь к SDK-эндпоинту vSphere в формате https://vcenter.example.com/sdk. Именно этот адрес обращён к API, а не веб-интерфейс vSphere Client — распространённая ошибка новичков подставить корень сайта и потом искать, почему шаблон «VMware template operation» не собирает данные.

Создаём в Zabbix хост с произвольным именем, добавляем ему интерфейс типа Agent (сам интерфейс не используется, но нужен для корректной привязки шаблона), прикрепляем шаблон «VMware» из штатной библиотеки. На вкладке Macros хоста переопределяем три указанных выше макроса значениями из нашей учётки read-only. После сохранения LLD-правила шаблона начнут отрабатывать через одну-две минуты — не сразу, потому что первый цикл vmware collector должен успеть заполнить кэш.

Штатные LLD правила автоматически обнаруживают хосты ESXi, датасторы, ВМ и создают под каждый объект отдельный хост-прототип с полным набором метрик. По нашему опыту это самая сильная сторона решения: добавили в vCenter новую виртуальную машину — через несколько минут она сама появилась в мониторинге, унаследовала триггеры и попала в нужную группу хостов. Ручной работы ноль. Ключи vmware.* под капотом делают всю работу.

Отдельно советуем сразу разложить обнаруженные ВМ по группам через макрос {$VMWARE.HV.UUID} и правила фильтрации в LLD. На кластере из нескольких сотен машин без фильтров вы получите один плоский список, в котором невозможно найти нужную ВМ.

Мы регулярно видим ещё одну ошибку: заказчик подключает vCenter, потом добавляет ещё отдельные ESXi «просто на всякий случай» — и получает дубли метрик, потому что vCenter уже отдаёт эти же хосты. Не делайте так: либо vCenter, либо standalone ESXi по прямому подключению — смешивать нельзя.

Что коллектор запустился и LLD-обнаружение пошло — видно в логе сервера сразу после привязки шаблона:

Standalone ESXi без vCenter подключается к мониторингу VMware Zabbix через штатный шаблон «VMware Hypervisor» — той же самой связкой макросов, что и vCenter, только URL указывает на API самого гипервизора. В {$VMWARE.URL} подставляем https://esxi.example.com/sdk, в {$VMWARE.USERNAME} — учётку с гипервизора, обычно локальную с ролью Read-only. Никаких скриптов и извлечения UUID вручную, как раньше в старых сценариях, современный шаблон делает всё сам.

Практический сценарий, когда это нужно: у клиента остались один-два отдельных гипервизора под резервные копии или тестовый стенд, лицензии vCenter на них нет и не будет, но метрики собирать надо. Мы такое настраиваем регулярно в связке «основной прод под vCenter + пара standalone ESXi под backup-инфраструктуру». В одном инстансе Zabbix 7.0 LTS это спокойно уживается — разные хосты с разными шаблонами.

Учётку на ESXi создаём в интерфейсе Host Client:

1. Manage → Security & users → Users → Add user, имя zabbix-monitor.
2. Manage → Security & users → Roles → создаём роль на основе Read-only или используем встроенную.
3. Actions → Permissions → Assign user to role в корне инвентаря хоста.

Из практики: на ESXi без vCenter периодически ломается SSL-сертификат — после переустановки хоста или смены имени. Zabbix при этом молча перестанет собирать данные, потому что vmware collector строго проверяет сертификат. Если у вас self-signed, поднимайте параметр отключения проверки TLS осознанно и только на изолированных сегментах — иначе получаете риск подмены. На проде мы всегда ставим корректный сертификат от внутренней CA.

Не смешивайте standalone-хосты и хосты из vCenter в одной хост-группе — при инцидентах в дежурке видно, кто из какой инфраструктуры, и это ускоряет реакцию. Мы разводим их по группам «ESXi standalone» и «ESXi vCenter», отдельно навешиваем разные наборы уведомлений.

Если метрики со standalone ESXi не появляются, первым делом смотрим лог сервера на ошибки сертификата и авторизации:

Триггеры на снапшоты старше нескольких суток, заполнение датасторов и события HA/vMotion — это тот минимум, ради которого мониторинг VMware Zabbix обычно и разворачивают. Штатный шаблон «VMware» отдаёт по каждой ВМ метрику возраста самого старого снапшота через ключи vmware.*, и на неё удобно повесить триггер с двумя уровнями важности — предупреждение на трёх сутках и авария на семи. По нашему опыту именно снапшоты — источник половины инцидентов на VMware-инфраструктуре: сначала «забытый» снапшот, потом полный датастор, потом упавшая ВМ.

Datastore usage мониторим по метрике vmware.datastore.size[url,datastore,pfree] — свободное место в процентах. Мы всегда ставим триггер на порог 20% для warning и 10% для average. Отдельно советуем следить за vmware.datastore.hv.list — если хост неожиданно отвалился от датастора, метрика меняется, и это отличный ранний сигнал проблем со стораджем или SAN.

Триггеры, которые обязательно ставим на каждом проекте:

• Снапшот на ВМ старше нескольких суток — по возрасту создания.
• Свободное место на датасторе ниже критического порога.
• ESXi в статусе Not Responding — по vmware.hv.status.
• Резкий рост числа vMotion за короткое окно — часто признак деградации хоста и переезда ВМ под давлением DRS.
• Появление событий HA restart в vCenter — ловим через event log и регулярку.

Кейс из практики. У заказчика вылетел один ESXi из четырёхнодового кластера, HA перезапустил на других хостах несколько десятков ВМ. Дежурная смена узнала об этом не через Zabbix, а от бизнеса — потому что триггера на HA restart не было, а падение одного хоста ночью «не разбудило» смену. После того случая мы включаем эти триггеры в дефолтный набор ещё на этапе внедрения и делаем отдельный высокий уровень severity, чтобы событие пробивало ночную тишину.

Не рекомендуем ставить триггер на «любой снапшот» — вы получите шквал ложняков от бэкапа. Правильный порог — только снапшоты, которые живут дольше окна резервного копирования. У Veeam это обычно несколько часов, у vRanger больше — ориентируйтесь на свой SLA.

Когда мониторинг VMware Zabbix не отдаёт данные, в 9 случаях из 10 виноваты три вещи: не запущены vmware collector’ы, переполнен VMwareCache или упирается сетевой таймаут до vCenter. Проверять их нужно строго в этом порядке, потому что дальше по цепочке проблема маскируется. Сначала смотрим zabbix_server.log на записи о VMware — там сразу видно, стартанул ли коллектор и есть ли ответы от SDK.

Ошибка «VMwareCache is full» — самая частая. Zabbix пишет её в лог и просто перестаёт обновлять часть данных, старые значения при этом остаются в интерфейсе, и админ на первый взгляд не понимает, что что-то сломалось. Мы поднимаем VMwareCacheSize в разы от дефолта на любых боевых инсталляциях с сотнями ВМ и повторно проверяем через сутки — если сообщение исчезло из лога, размер подобран корректно.

Таймауты появляются, когда vCenter отвечает медленно, а Zabbix ждёт мало. Симптомы — периодические разрывы графиков, «дырки» на пять-десять минут, редкие срабатывания nodata-триггеров, которые тут же гаснут. Решение — поднять Timeout в конфиге сервера, но осторожно: большие значения тормозят все остальные поллеры. Мы обычно вешаем vCenter на отдельный Zabbix-прокси с собственным таймаутом.

По нашему опыту почти все «странные» проблемы с VMware в Zabbix упираются в одно из трёх:

• Не хватает StartVMwareCollectors — метрики просто не появляются.
• Не хватает VMwareCacheSize — метрики появляются, но перестают обновляться.
• Слетел сертификат SSL или сменился пароль read-only учётки — в логе явные ошибки авторизации.

Отдельно советуем не пытаться отладить это через zabbix_get с параметром vmware.version — этот ключ выполняется на стороне сервера, а не агента, и zabbix_get его не увидит. Значения смотрите в Latest data по хосту vCenter напрямую в веб-интерфейсе и сверяйтесь с официальным quickstart-гайдом по VMware в документации Zabbix 7.0.

А на стороне сервера те же три причины быстро отсекаются набором команд — в описанном порядке:

Ответы на часто задаваемые вопросы по теме статьи.

Константин Тютюнник — ведущий инженер IT For Prof с опытом внедрения систем мониторинга в крупных виртуальных инфраструктурах. Специализируется на оптимизации производительности Zabbix Proxy и настройке сложных правил обнаружения для VMware vSphere.