Комментарии 25
Сергей, подозреваю, что для рынка РФ все гораздо сложнее, поскольку Zabbix все же бесплатный продукт, тогда как zVirt - ваш коммерческий ребенок. И, увы, в сегодняшних реалиях все считают деньги.
Да, все так. Но в уравнении для подсчета денег также не стоит забывать и траты времени на управление и развитие опенсорсного мониторинга. Мы со своей стороны подготовили нативное решение и предоставили возможность для выбора
использовать zVirt Metrics для глубокой аналитики виртуализации, а агрегированные показатели вроде утилизации или статуса кластера экспортировать в Zabbix
Так кроме виртуализации надо и всё остальное мониторить - zVirt Metrics умеет? Или ставить рядом Zabbix всё равно придётся? Тогда зачем два решения вместо одного, да ещё и за деньги?
Если так и так понадобится спец для тюнинга Zabbix, то можно не покупать платное решение, а отдать деньги на тюнинг бесплатного.
Я не утверждаю, что zVirt Metrics заменяет Zabbix. Metrics из коробки отдает глубинные метрики самой виртуализации — то, что Zabbix увидит после тонны настроек: состояние кластера, storage, HV и внутренние события платформы.
Zabbix никуда не уходит для остальной инфраструктуры, а zVirt Metrics гарантированно закрывает критичную слепую зону
В Zabbix мониторинг zVirt строится через Zabbix Agent 2 с плагином zVirt. Агент ходит по REST API движка, собирает метрики и шлёт их на сервер, где лежит база (MySQL или PostgreSQL). Всё по классике: поставил агент — получил данные.
Из статьи не очень понятно где располагается API zVirt и зачем вы туда ходите именно агентом?
Можно прикрутить TimeScaleDB и ужать хранение примерно в 10 раз, но придётся руками создавать гипертаблицы и включать компрессию — не для слабонервных.
Про установку TimeScaleDB в PostgreSQL вы немного слукавили, там далеко не всё так страшно, но с первого раза может не получиться.
Дополнительно спрошу, вы занимались тюнингом шаблонов, по которым опрашивали узлы?
Zabbix живёт в парадигме push
Zabbix до сих пор поддерживает как пассивный поллинг (pull) так и активный (push).
Zabbix начинает сдавать гораздо раньше. Уже при ~100 виртуальных машинах и около 4000 элементов данных появляются первые симптомы перегрузки.
Здесь бы не помешали характеристики ВМ, на которой развёрнута система мониторинга и где хранится её БД.
Zabbix: немного магии, много ручной работы
Опять спрошу про агент. И.. ну, деплой zabbix довольно шаблонный, если у вас несколько идентичных мест для деплоя. Ansible?
REST API в zVirt это как раз новая часть, которая появилась после наших доработок с версии zVirt 4.4. Ее нет в oVirt. Агент работает с этим интерфейсом внутри HostedEngine и передает данные в серверную часть Zabbix по стандартной цепочке. Судя по другим возможностям Zabbix можно его настроить и другим способом, но мы оставляем эту задачу на отдел мониторинга в заказчиках
В чем же принципиальная разница в скорости опроса одного и того же API с использованием двух инструментов вашей разработки:
плагина для Zabbix
zVirt Metrics
Попробовал использовать zVirt API для мониторинга. Был очень недоволен тем, что системный журнал HE забился бесчисленными событиями входа через API, и найти там что-нибудь нужное стало проблематично. Пришлось отказаться.
В API интерфейсе oVirt нас тоже не устраивало поведение, поэтому мы сделали отдельный REST API для метрик. Детальнее информация представлена в в статье на wiki
В Zabbix мониторинг zVirt строится через Zabbix Agent 2 с плагином zVirt. Агент ходит по REST API движка, собирает метрики и шлёт их на сервер, где лежит база (MySQL или PostgreSQL).
Не дадите ссылку на этот плагин для Zabbix Agent 2? Не могу найти. Агент ставить совсем необязательно. Вы можете забирать все данные при помощи HTTP при помощи Zabbix Server или Zabbix Proxy.
Я предполагаю, этот абзац больше про рекламу плагина zVirt, иной причины вот так изгаляться представить не могу.
Zabbix в версии 6 были неудобства пользования http-запросов. Например, если вам сначала надо запросить токен у опрашиваемой системы, а потом уже с ним ходить по API. Т.е. снабжать запрос заголовком Authorization: Basic login:pass здесь не вариант совсем. В один запрос средствами UI Zabbix сделать этого не получится. Проверка делает 1 запрос и дальше пляшет от ответа. Следовательно, если к моменту выполнения запроса элемента данных у вас нет токена, вы в лучшем случае получите 401 от проверяемого объекта, а если вы этот токен и запрашиваете, то не очень понятно, как его передать в другие элементы данных. Плюс встаёт вопрос как за собой "закрыть" открытую токеном сессию, если проверки вы осуществляете достаточно редко. Самописными скриптами решить эту задачу - да, без проблем.
Задачи получения токена уже решены через тип Scripts. Можно сделать по примеру шаблона для AWS S3 bucket by HTTP.
Вот пример рабочего кода на Powershell, работающий с zVirt WEB API. Это не метрики, но наверное там похожее. Сомнения, что это нормально будет работать напрямую в Zabbix. А плагин, наверное, делает всю грязную работу и выдает этот гигантский JSON "нате, разбирайте".
# Параметры подключения
$zvirtUrl = "https://host.fqdn"
$username = "your-login@internal"
$username = [Uri]::EscapeDataString($username)
$password = "verysecretpassw0rd"
$password = [Uri]::EscapeDataString($password)
$tokenUrl = "$zvirtUrl/ovirt-engine/sso/oauth/token"
$body = "grant_type=password&scope=ovirt-app-api&username=$username&password=$password"
$headers = @{
"Content-Type" = "application/x-www-form-urlencoded"
"Accept" = "application/json"
}
$response = Invoke-RestMethod -Uri $tokenUrl -Method Post -Headers $headers -Body $body
$response.access_tokenА тело скрипта пишется на JS, да?
Основная информация находится в статье на wiki
Основная информация находится в статье на wiki
Заметил, что часть читателей восприняла статью так, будто Metrics – это замена Zabbix. Это не отражает мою позицию. Чтобы избежать дальнейших недопониманий, добавил спойлер в начале материала
Не так вы дядя Федер бутерброд кушаете ……сравниваете … понятное дело, что больше для рекламы этого, но как-то все сумбурно накидали …не знаю, 5000 хостов, zabbix обслуживает нормально, еще делают некую автоматизацию… после прочтения поста желание перелазить или даже потестировать не возникло…, а) так и не понял из чего сделано решение, что под капотом и так далее б) на сколько туманное или светло будущее по развитию решения …
Zabbix же, вроде, давно умеет работать с данными в формате Prometheus? Почему нельзя их тогда брать с того же API, что и zVirt metrics?
Краткое содержание статьи:
Если вы упираетесь в парсинг стопицот параметров от стопицот виртуалок на своем дохлом заббиксе, то может нужно задуматься, а зачем вам все эти параметры-то в самом заббиксе-то.
Через javascript дергаете нужное внешнее API, получаете десяток нужных метрик для каждой виртуалки, которые по факту используются триггерами.
А остальное смотреть на красивых дашбордах в grafana из prometheus с детализацией в scrape_interval 15s
zVirt Metrics vs Zabbix: где заканчивается универсальный мониторинг