Zabbix — отличный универсальный инструмент. Но как только виртуалок становится не 20, а 200, всё превращается в бесконечный тюнинг: поднял лимит PHP, подкинул кэш, вырубил логирование — и надеешься, что доживёт до утра. Мы проверили, где эта грань на самом деле проходит и как себя ведёт альтернатива — zVirt Metrics. В статье — архитектура, производительность и честные цифры из тестов. Материал будет полезен инженерам, которые держат на себе мониторинг виртуализации и хотят, чтобы всё работало из коробки и без плясок с бубном при росте числа инсталляций zVirt.

---

Введение, или Архитектура решений

Сравнивать Zabbix и zVirt Metrics лоб в лоб бессмысленно — они просто из разных миров.

Zabbix — это классика жанра: универсальный мониторинг всего подряд — серверов, сетей, приложений. Разворачивается обычно как монолит, надёжный, предсказуемый, но не слишком гибкий.

zVirt Metrics, наоборот, родилась как узкоспециализированная штука под виртуализацию zVirt. У неё распределённая архитектура: нагрузка раскидана по сервисам, каждый отвечает за свой кусок и масштабируется отдельно.

Чтобы не сравнивать яблоки с апельсинами, мы смотрим только на то, что реально важно в эксплуатации:

• сколько CPU и памяти уходит на сбор данных с API zVirt;

• сколько диска нужно, чтобы хранить метрики в одинаковом объёме.

Тесты проводились на Zabbix 7.0.19 + PostgreSQL 15 и zVirt Metrics 1.1.

Zabbix: агент, JSON и внезапные 3,5 ядра

В Zabbix мониторинг zVirt строится через Zabbix Agent 2 с плагином zVirt. Агент ходит по REST API движка, собирает метрики и шлёт их на сервер, где лежит база (MySQL или PostgreSQL). Всё по классике: поставил агент — получил данные.

Но на практике при ~600 виртуальных машинах всё становится веселее. Агент стягивает у API один здоровенный JSON примерно на 16 МБ — полный снимок состояния. Дальше он сам его парсит и жрёт до 3,5 ядра CPU раз в минуту. Если агент сидит на продовом узле — это чувствуется.

Хранилище — обычная реляционная база, и это главный тормоз.

При 20 000 items и 25,7 млн точек таблицы history и history_uint съедают 2,47 ГБ (≈103 байта на точку). Так и должно быть по документации.

Можно прикрутить TimeScaleDB и ужать хранение примерно в 10 раз, но придётся руками создавать гипертаблицы и включать компрессию — не для слабонервных.

zVirt Metrics: меньше агентов, больше воздуха

zVirt Metrics ставится через Deploy Manager, который разворачивает весь стек сразу — базы, визуализацию, аналитику.

Метрики тянутся по модели pull, с низкой задержкой. Сборщик работает как Prometheus-экспортер, но встроен в zVirt, так что никаких агентов по узлам ставить не надо. Это сразу убирает массу рутинных проблем.

Хранение — на VictoriaMetrics. В тестах она переварила 652 млн точек на 378 МБ — примерно 0,6 байта на точку против 103 байт у PostgreSQL. Разница — в 171 раз.

Если пересчитать на год при 50 000 метрик в минуту:

• zVirt Metrics займёт ~14,7 ГБ;

• Zabbix с PostgreSQL — ~2,5 ТБ;

• Zabbix с TimeScaleDB — ~256 ГБ.

Даже с поправкой на retention и частоту опроса порядок цифр сохраняется.

В стек входят ClickHouse для аналитики, Grafana для дашбордов, Superset для BI и Airflow для ETL-пайплайнов. Всё это работает вместе без шаманства.

Push vs. Pull

Zabbix живёт в парадигме push: агент сам пушит данные на сервер. Это даёт стабильную сетевую нагрузку, но требует ручной возни на каждом узле.

zVirt Metrics использует pull, как в Prometheus: центральный сборщик сам опрашивает API zVirt. Service discovery упрощается, администрирование — тоже.

Разница по сути в философии:

• Zabbix — это универсальность и агенты;

• zVirt Metrics — централизованный сбор и TSDB, которая не задыхается от миллиона метрик.

Допустим архитектура красивая — на бумаге. Но дальше начинается самое интересное: как это живёт на практике и насколько сложно всё это завести и не сломать.

Удобство настройки и использования

Теперь к практике. Архитектура — это красиво, но когда дело доходит до установки, всё решают два вопроса: насколько больно это ставить и как потом с этим жить.

Zabbix: немного магии, много ручной работы

Развернуть Zabbix под мониторинг zVirt — занятие не из быстрых. Сначала ставим сервер Zabbix с базой данных и веб-интерфейсом, потом — агент на hosted engine или на выбранном узле, докручиваем плагин zVirt.

Дальше начинается привычная рутина: прописываем в конфиге URL, логин, пароль к API, правим доступы к файлам, открываем порты в firewall.

Если zVirt развёрнут не в одном месте, а, скажем, в нескольких датацентрах — готовьтесь ставить отдельный агент под каждую площадку. На старте это терпимо, но при масштабировании превращается в лишний головняк.

После установки можно взять готовый шаблон для zVirt — он включает базовые правила обнаружения, так что стартовать просто.

Но дальше всё упирается в кастомизацию: хотите дополнительные метрики или дашборды — придётся писать UserParameters, городить calculated items и собирать визуализации вручную.

В больших инсталляциях это уже не настройка, а мини-проект с собственным трекером задач.

zVirt Metrics: «развернул — и работает»

В zVirt Metrics всё устроено проще. Deploy Manager сам оркестрирует установку — базы, визуализацию, аналитику. После деплоя система уже готова к работе:

• дашборды Grafana для мониторинга виртуализации,

• Superset для бизнес-аналитики,

• Airflow для ETL-процессов.

Из коробки всё это умеет фильтровать по датацентрам, кластерам, хостам и виртуальным машинам. То есть сразу видно общую картину — без ручного шаманства и настройки виджетов.

Масштабирование метрик: где Zabbix захлёбывается

Классическая боль Zabbix — это лавина элементов данных, которую генерирует Low-Level Discovery. При масштабе ~600 виртуальных машин шаблон создаёт десятки тысяч items и triggers.

Результат предсказуем:

• интерфейс начинает тормозить;

• поиск нужной метрики превращается в квест;

• массовое редактирование — в бесконечный клик-марафон.

В zVirt Metrics метрики организованы иначе — иерархически: датацентр — кластер — хост — хранилище — ВМ.

Навигация остаётся чистой и логичной, даже если инфраструктура разрослась. Нет этого ощущения, что система сама себя засыпала данными.

Повседневная работа и отчётность

Визуализация — ещё один показатель зрелости системы.

Zabbix даёт базовый набор: шаблон, пара графиков, немного ручной магии. Чтобы собрать полноценный дашборд, приходится по частям добавлять элементы, настраивать диапазоны и форматы.

На один хороший экран уходит 4–8 часов инженера, а если нужны отчёты или тренды — чаще всего всё сводится к экспорту данных в внешние BI-системы.

В zVirt Metrics это выглядит иначе.

Из коробки доступны:

• Grafana с преднастроенными дашбордами,

• Apache Superset с drag-and-drop аналитикой,

• SQL Lab для произвольных запросов к ClickHouse,

• Airflow для автоматизации отчётов.

Собрать executive dashboard с основными метриками можно за 15–30 минут, без скриптов и плясок с бубном CSV.

Когда Zabbix всё ещё уместен

Несправедливо было бы сказать, что Zabbix «не нужон».

Если он уже стоит и мониторит сервера, сети и приложения — добавить плагин zVirt логично. Вы получите единый контур мониторинга и сохраните привычный процесс работы с алертами и интеграциями.

Для малых инфраструктур (до 100 ВМ) Zabbix действительно проще и легче по ресурсам: single-node сервер с PostgreSQL можно поднять на обычной виртуалке.

Полный стек zVirt Metrics потребует куда больше мощности и памяти.

Впрочем есть и компромисс — гибридная схема: использовать zVirt Metrics для глубокой аналитики виртуализации, а агрегированные показатели вроде утилизации или статуса кластера экспортировать в Zabbix.

Так можно совместить удобство централизованных алертов с преимуществами специализированной аналитики.

Ну ладно, с установкой разобрались. А что происходит, когда система выходит за рамки тестового стенда и в дело вступают сотни виртуалок?

Поведение при увеличении нагрузки

Развернули, всё работает — пока метрик не стало слишком много. Вот тут и проявляется разница между системами: одна растёт вместе с инфраструктурой, а вторая начинает задыхаться.

Масштабируемость zVirt Metrics

zVirt Metrics при росте нагрузки ведёт себя предсказуемо. VictoriaMetrics изначально спроектирована под горизонтальное масштабирование: вырос объём метрик — добавь узел хранения, и всё продолжает работать без плясок с конфигами.

Система не требует постоянного «допиливания» словно дедушкина восьмерка простоявшая в гараже 5 лет.

Горячее и холодное хранение разделяются автоматически, данные сжимаются эффективно, а сама архитектура распределена так, чтобы не возникало узких мест. Даже если количество метрик растёт экспоненциально, производительность и отклик остаются стабильными — просто масштабируешь горизонтально и живёшь спокойно.

Проблемы масштабирования Zabbix

Zabbix начинает сдавать гораздо раньше. Уже при ~100 виртуальных машинах и около 4000 элементов данных появляются первые симптомы перегрузки.

Главная боль — логирование JavaScript-препроцессинга. Начиная с версии 7.0, Zabbix урезал лимит логов до 8 МБ, и дальше остаётся только одно решение — вырубить логирование совсем. В итоге теряется наблюдаемость и нормальная отладка.

Дальше — хуже. При ~600 ВМ и 20 000 items нагрузка растёт лавинообразно. Система начинает требовать увеличения лимитов для процессов, а веб-интерфейс начинает сыпаться на ровном месте.

Попробуешь открыть Latest data — и получаешь:

PHP просто не выдерживает объёма данных. Добавить график? «Unexpected server error».

Навигация? Каждая операция тянется по несколько секунд.

Чтобы Zabbix не лёг окончательно, приходится костылить: поднимать кэш конфигурации до 100–500 МБ, увеличивать лимиты памяти PHP, чистить старые данные. Но это не решение — архитектура просто не рассчитана на десятки тысяч метрик и триггеров.

Навигация по хостам превращается в медленный квест, а поиск нужной метрики — в испытание на терпение.

Почему TSDB решает проблему

Вся разница — в архитектуре хранения. PostgreSQL и MySQL, на которых держится Zabbix, изначально проектировались под транзакционные нагрузки: сложные JOIN’ы, ACID-гарантии, всё как положено бизнес-приложениям.

Но для метрик это лишний балласт — тут важны скорость записи и чтения последовательных измерений, а не транзакционная чистота.

VictoriaMetrics и ClickHouse, наоборот, сделаны под работу с временными рядами и аналитикой. Колоночное хранение ClickHouse позволяет читать только нужные колонки — агрегации летят на порядки быстрее.

Поверх этого в zVirt Metrics работают ETL-пайплайны: Airflow собирает, агрегирует и отправляет данные в ClickHouse, формируя аналитические витрины для дашбордов.

«Сырые» временные ряды остаются в VictoriaMetrics — можно пересчитать метрики, поменять агрегацию, расширить отчётность, не потеряв историю.

Итог предсказуем: zVirt Metrics масштабируется без боли, а Zabbix требует всё больше ручных правок и внимания (привет личное выгорание).

Специализация метрик и глубина мониторинга

zVirt Metrics изначально заточен�� под платформу виртуализации — и это сразу чувствуется по глубине данных. Система собирает около 140 специализированных метрик, сгруппированных по пяти уровням:

датацентры, кластеры, хосты, хранилища и виртуальные машины.

Для каждого уровня свой набор показателей:

• статус storage domains;

• политики балансировки кластеров;

• подробности по vCPU и vRAM вплоть до каждой виртуалки.

Но фишка не в количестве, а в том, как эти данные связаны между собой. Метрики не живут отдельно — они описывают всю экосистему виртуализации в связном контексте.

Можно, например, одним запросом вытащить все ВМ, которые работают на хостах с высокой загрузкой CPU и лежат на storage domains с повышенной латентностью.

Это уже не просто мониторинг, а почти расследование: видно не симптом, а причину.

Zabbix подходит к делу проще. Стандартный шаблон даёт около 66 метрик — CPU, память, сеть, состояние ВМ, базовые параметры хранилищ. Этого достаточно, чтобы знать, «живы ли сервера», но недостаточно для понимания, почему кластер ведёт себя странно.

Чтобы добраться до такой же глубины, приходится вручную добавлять кастомные элементы данных, городить calculated items и связывать всё между собой вручную.

Именно поэтому zVirt Metrics даёт из коробки то, что в Zabbix обычно превращается в долгий тюнинг и полдня правок в шаблонах.

Короче, с метриками понятно: одна система знает о платформе всё, вторая — только что она дышит. Теперь осталось понять, в каких сценариях каждая из них реально уместна.

Сценарии применения и рекомендации

zVirt Metrics раскрывает себя там, где инфраструктура уже выросла — от сотни виртуальных машин и выше. Тут важно не просто снимать метрики, а видеть закономерности: где тонко, где перераспределить нагрузку, как спланировать ёмкость.

Система изначально строилась вокруг аналитического ядра. Если Zabbix — это про «увидел, что упало, и побежал чинить», то zVirt Metrics — про анализ, прогноз и нормальную жизнь без паники.

Она чувствует себя уверенно в средах с высокой кардинальностью метрик, большими объёмами данных и долгосрочным хранением.

А в распределённых инфраструктурах выигрывает за счёт централизованного управления: меньше ручной возни, меньше шансов, что что-то разойдётся между площадками, и предсказуемое масштабирование, когда метрик становится в разы больше.

Zabbix при этом сбрасывать со счетов точно не стоит.

Для небольших и средних установок — до 50 хостов и 10 тысяч метрик в минуту — это по-прежнему отличное решение. Особенно если мониторинг уже выстроен, интеграции с ITSM настроены, а аналитика «в разрезе секунд» не нужна.

Здесь универсальность Zabbix — его сильная сторона: всё в одной консоли, персонал обучен, процессы привычные. Это тот случай, когда проще не значит хуже — просто система решает другие задачи.

На практике чаще всего побеждает гибрид.

zVirt Metrics берёт на себя глубокий мониторинг и аналитику виртуализации, а Zabbix продолжает следить за остальным ландшафтом — серверами, сетями, приложениями.

Обе системы спокойно живут вместе: метрики можно свести в Grafana, сделать общий дашборд и при необходимости проваливаться (drill-down) из Zabbix в панели zVirt Metrics, когда нужна детализация по кластерам или конкретным ВМ.

Такой вариант сочетает простоту и централизацию Zabbix с глубиной и аналитическими возможностями zVirt Metrics — каждая система остаётся в своей стихии, и никто никому не мешает.

Мы поделились своими цифрами — теперь ваша очередь. Живёте на Zabbix, пилите свои костыли или уже пробовали что-то вроде zVirt Metrics?