Чем Glaber отличается от Zabbix
архитектурное отличие:
Zabbix ведет себя как stateless приложение. Все изменения в структуре мониторинга сервер проецирует в базу SQL. Zabbix очень похож на финансовое приложение с транзакциями: все что было собрано - будет обработано и записано. Четко, надежно, но требует много ресурсов. В базе хранится все. Сделано все, чтобы собранные данные попали в базу. Недостаток – из низкой скорости базы на больших объемах тормоза и много данных не собирается.
В Glaber приоритетным считается оперативный мониторинг. Принимаются все меры, чтобы состояние инфраструктуры максимально оперативно и точно отражалось в API/UI, а база вторична. Glaber может откладывать заведомо тяжелые задачи в угоду общей скорости работы. Например, для быстрого старта, вычисление некоторых триггеров может быть отложено.
Технически:
Изменена архитектура поллинга
Используются асинхронные способы работы с сетью по популярным проверкам, это дает прирост до 1000 раз по скорости поллинга, особенно в случаях массовых проблем в сети. Сейчас поддерживаются в асинхронном поллинге протоколы: snmp, agent, tcp simple checks.
Также для icmp проверок может использоваться спец. поллер на базе zmap – эффективнее fping решения от zabbix по затратам процессора примерно в 100раз.
Примечание
Заббикс в версии 7.0 обещает также запустить асинхронный поллинг, так что эта информация может стать неактуальной.
Асинхронные поллеры в Glaber не блокируют кеш конфигурации
Это дает возможность снимать сервером в сотни раз больше метрик, не вызывая событий внутренних блокировок.
Состояние метрик и триггеров хранится в памяти сервера
Хранение осуществляется в низкоблокируемых структурах, и не пишется в SQL - дополнительно снижается нагрузка на базу
Метрики пишутся в timeseries базы, и могут читаться оттуда
Это дает 30-100 кратную экономию на ресурсах процессора и занятого диска относительно SQL хранения. По IOPS экономия примерно 1000 кратная.
Последние значения метрик, состояния айтемов, триггеров берутся напрямую из памяти сервера
... а не SQL базы – что позволяет сильно улучшить UI в плане скорости работы
Измененный виджет последних данных
C иконками, превьюшками графиков, табличным отображением, живой фильтрацией
Улучшенная навигация
Если идет просмотр в контексте узла, то узел и его типовые ссылки отображаются сквозняком на всех панелях.
Реализована концепция зависимостей между узлами
В рамках работы над над сервисной моделью реализованы связи между злами. Реализован модуль графического отображения такой связности. Связность, в том числе, может формироваться на основе собранных данных
Несколько новых правил препроцессинга
Новые правила позволяют реализовать принципиально новые задачи: - обработка логов, - netflow, - распределение метрик по хостам на основе входящих данных, - генерация LLD для метрик на основе входящих данных
Реализована идея воркеров
Воркеры это легкий способ расширения функционала ядра мониторинга для работы с различными внешними системами: как для приема новых видов метрик, так и для обработки и сохранения метрик в новые виды хранилищ
Переписан кеш значений
Используется малоблокируюмая модель данных, позволяет линейно масштабировать емкость сервера. Оптимизированы некоторые запросы в кеш, уменьшающие использование "дорогого" хранилища метрик.
Кеш значений периодически выгружается на диск
Такое решение дает быстрое заполнение кеша на старте, и главное, решает проблему проседания скорости работы при наполнении кеша метрик из хранилища истории. При одинаковых условиях глайбер стартует в сотни раз быстрее заббикса на больших конфигурациях.
Используется система приоритезации хранения и чтения метрик
При высоких задержках на чтение системы хранения метрик сервер может откладывать операции чтения. Это дает увеличение производительности записи метрик в десятки раз при тормозах выборок из системы хранения.
Также приоритезация обеспечивает безболезненный старт сервера даже с холодным кешем метрик (в одном из кейсов глайбер стартовал и проходил первый полный цикл съема метрика за 6,5 минут, в тех же условиях заббиксу требовалось более 4 часов на полноценный старт).
Скорость работы препроцессинга и пайплайна обработки метрик
В Zabbix есть несколько существенных ограничений: скорость обработки метрик в preprocessing manager ( ок 70-80к NVPS при наличии шагов препроцессинга), HistoryCache - около 140кNVPS. Реально достижимы на заббиксе скорости съема данных – до 30-40к NVPS.
Примечание
В Zabbix 6.4 модель препроцессинга оптимизирована и убрано два плеча сериализации в воркер и обратно, скорее всего эффективность препроцессинга будет на уровне HistoryCache. Однако менеджер препроцесснга по-прежнему остается бутылочным горлышком.
В Glaber эти проблемы решены и с версии 3.1 на однопроцессороной машине без тюнинга производительности достигаются скорости в 400к NVPS. Есть основания считать, что на многопроцессорных системах достижимы скорости обработки до 1M NVPS
Использование CPU ниже
затраты сервера по CPU в Glaber ниже за счет очень эффективного IPC основного пайплайна метрик. Экономия примерно 0,5 - 1 CPU на каждые 50к NVPS.
Есть выборочная отладка метрик
Позволяет на ходу диагностировать частные проблемы с путем и логикой обработки метрик без включения массового режима отладки, зачастую вызывающего общую деградацию скорости работы, что позволяет оперативно диагностировать проблемы со съемом метрик или с работой триггеров