История

В начале 2018 года крупная ИТ компания, в которой я руководил ИТ отделом, была на пороге очередного апгрейда инфраструктуры мониторинга. Тогда у нас работал Zabbix на 21 сервере, в основной массе - прокси.

Работал он неудовлетворительно — при массовых проблемах мониторинг сам "ложился" от нагрузки, скорость и периодичность опроса оборудования не устраивала.

В рамках "хакатона" я за выходные сделал прототип, который использовал ClickHouse для хранения истории и отображения графиков. Тогда это был набор патчей - костылей, но как "Proof of concept" он показал себя хорошо.

В те дни у меня было понимание, что стоит только о таких улучшениях рассказать миру, и мир сам сделает такую классную интеграцию и апгрейд. Мы с выступали на конференциях, съездили даже на Zabbix summit и рассказали там. Но мир нас не услышал. Ок, как говорится:

"хочешь сделать хорошо - сделай сам"

В 2019 году набор накопившихся изменений был назван проектом Glaber. К этому моменту к проекту присоединилось несколько человек — кто-то помогал с CI/CD, кто-то использовал проект у себя, кто-то о нем рассказывал другим.

С начала 2021 у проекта образовалось некоторое комьюнити, было запущено порядка 20 рабочих инсталляций. А с начала 2021 года я смог большую часть своего времени уделять проекту, начал строить команду и реализовывать то, что давно просилось:

Я слышал о других системах сбора метрик и визуализаций. Есть основания считать, что некоторые лучше чем Zabbix. Но есть и ряд причин, по которым Zabbix и Glaber весьма актуальны:

• система "все в одном" (от сбора до визуализации);

• хорошо развитые триггеры, система оповещений и эскалации;

• удобное API для внешней интеграции.

Что такое - Glaber?

Это форк, основанный на исходных кодах Zabbix, который мы развиваем и поддерживаем.

Проект хорошо масштабируется и прекрасно зарекомендовал для мониторинга относительно статичных инфраструктур. Большинство известных мне инсталляций мониторят оборудование и его доступность.

Последние изменения, которые есть в Glaber, позволяют использовать его и для высоко-динамичного мониторинга.

Отличия в архитектуре и философии между Zabbix и Glaber

Zabbix ведет себя как stateless приложение. Все изменения в структуре мониторинга сервер проецирует в базу SQL. Zabbix очень похож на финансовое приложение с транзакциями: все что было собрано - будет обработано и записано. Четко, надежно, но требует много ресурсов. В базе хранится все. Сделано все, чтобы собранные данные попали в базу.

В Glaber приоритетным считается оперативный мониторинг. Принимаются все меры, чтобы состояние инфраструктуры максимально оперативно и точно отражалось в API/UI, а база вторична. Glaber может откладывать заведомо тяжелые задачи в угоду общей скорости работы. Например, для быстрого старта, вычисление некоторых триггеров может быть отложено.

Сходства Glaber и Zabbix

Визуально системы очень похожи. Интерфейс Glaber такой же как у Zabbix и нет необходимости привыкать к новому.

У них одинаковая SQL база. База конфигурации мониторинга по составу таблиц и полей не отличается в Zabbix и Glaber.

Есть прямая и обратная совместимость, за исключением исторических данных (history* таблиц), Glaber их не использует, так как работает с внешними хранилищами истории

Можно запустить Glaber на той же базе, на которой работал Zabbix. И наоборот. Конфигурации и настройки сохранятся.

Ключевые функции Glaber

Glaber работает с современными хранилищами истории:

Сейчас поддерживаются ClickHouse, VictoriaMetrics, InfluxDB. Для поддержки новой базы данных можно написать плагин-адаптер на любом языке, изменение кода самого сервера не требуется.

Более развитое API хранения метрик

• Поддерживается работа с внешними модулями – воркерами
• работа с несколькими хранилищами историй одновременно
• возможна фильтрация по типу данных и по характеру данных (история или тренды). Например, можно писать сразу в две разные базы ClickHouse (если нет желания собирать полноценный кластер, но нужен резерв):

Можно настроить разные сценарии работы с историей. Например, хранить историю в VictoriaMetrica а тренды и строковые данные в ClickHouse.

Интеграция внешних хранилищ полная.

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

Быстрая работа c оперативными данными

Glaber отдает оперативные данные о состоянии объектов из памяти сервера и не пишет их в SQL. Это дает два важных плюса:

• быстро работают WEB интерфейсы
• не тормозит от нагрузки SQL база.

Это важно, так как до момента массовых аварий мы часто не знаем, что упираемся в SQL.

Модульность

Использование воркеров - адаптеров позволяет легко наращивать функционал, поддерживаемые протоколы и способы съема метрик.

В Glaber реализована идея постоянно работающих внешних служб, которые запускает сервер. Такие службы называются воркерами, они могут быть написаны на любом языке. В том числе в самом Glaber есть воркеры, написанные как отдельные приложения на языках Go и на С.

Основная функция воркеров - адаптация того или иного API Glaber под конкретную задачу, формат, систему.

Сейчас воркеры:

• реализуют интерфейс к разным хранилищам истории;
• работают как внешние скрипты;
• работают как сервера для приема новых типов данных, например, логов;

Например, воркеры используются в задаче "эффетивного пинга". В этом случае в качестве воркера работает утилита glbmap, которая использует повышенные права для работы с RAW socket.

Может собирать, оцифровывать и хранить логи

И не только логи.

Glaber может быть "сервером" для любого типа данных.

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

Рaсширенные функции препроцессинга и автосоздания хостов c использованием LLD и шаблонов позволяют настроить системы, где можно просто «лить» данные на сервер мониторинга, при этом все необходимые объекты сервер создаст сам по шаблонам.

C версии 2.4.0 в Glaber вышел релиз воркера, который принимает данные по протоколу Syslog и таким образом реализует прием логов. Расширенные функции препроцессинга позволяют «оцифровывать» логи в графики.

Имеет расширенные возможности по препроцессингу данных

В Glaber в препроцессинг добавлены новые функции:

• можно запускать несколько препроцессоров, что убирает общее ограничение в 70-90 тысяч новых метрик в секунду на систему;
• препроцессоры приоретизируют задачи в зависимости от нагрузки. Если очередь на обработку становится слишком большой, то приостанавливается обработка данных, не допуская бесконтрольного потребления памяти;

в препроцессинге введены функции агрегации данных по времени - max, min, sum, count, avg. Агрегация с типом count позволяет реализовать подсчет частотности данных, в том числе, нечисловых - это, например, позволяет визуализировать логи.

Быстро стартует

Glaber периодически выгружает одним файлом дамп кеша истории и состояния объектов.

При старте этот файл быстро и эффективно читается, позволяя избежать затрат на чтение исторических данных из хранилища истории.

Совместно с функцией ограничения времени на чтение из API истории это дает очень быстрый старт и переход к устоявшемуся режиму работы с прогретым кешем.

Высокопроизводительные поллеры

Glaber использует заново написанные поллеры AGENT, SNMP, ICMP, внешние воркеры, воркеры в режиме серверов.

Работа с этими протоколами и сервисами сделана эффективно:

• в асинхронном режиме;
• использует собственные кеши конфигурации;
• не использует SQL;
• ориентируется на большие нагрузки.

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

Может лучше масштабироваться

Большинство мер в предыдущих пунктах приводят к существенному уменьшению ресурсов и увеличению производительности. Именно поэтому в свое время 21 сервер мониторинга мы трансформировали в 2. Приведу конкретные цифры.

Одна из сопровождаемых мною инсталляций собирает около 40 тысяч новых значений в секунду. Это 6 миллионов уникальных метрик и примерно 100 тысяч устройств.

Конфигурация работает на одном сервере, однопроцессорной машине с Xeon1280 и 32G памяти, совмещает работу с SQL сервером. Хранение истории делается вне этого сервера, но потенциально возможно локально хранить и историю. Для ClickHouse и VictoriaMetrics нагрузки мизерные.

Тесты показывают очень хорошие возможности для роста. На сервере с 16 поточным Xeon в Glaber удавалось обрабатывать более 250 тысяч метрик в секунду (от приема до выгрузки в хранилище истории).

Глайбер и цифры

на одном современном сервере можно сейчас можно собирать: 10 Млн различных метрик

записывать новые данные cо скоростью 150 тысяч метрик в секунду

опрашивать 100 тысяч устройств

хранить данные несколько лет

Q&А: Про стабильность, поддержку, живучесть проекта, исходники

Q1: Это же opensource?

Да, на гитлабе можно скачать исходники. https://gitlab.com/mikler/glaber. Документация находится по адресу https://docs.glaber.io

Q2: А сложно ли и можно самим эксплуатировать Glaber?

Не сложно. Специалист, имевший знакомство с установкой заббикс, и умеющий пользоваться Google и StackOverflow вполне сможет решить большинство вопросов. Как правило, после начальной установки, их возникает мало – так как зачастую основной источник проблем это перегруженная SQL база, а в Glaber база нагружена на порядки меньше.

Q3: А что, если в Zabbix будет реализована функция, которой сейчас нет в Glaber, но очень нужна?

Glaber примерно раз в полгода обновляет исходный код Zabbix, на котором он основан. Сейчас это 5.4.11, готовится релиз версии Glaber3.0 на основе версии заббикс 6.4.

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

Q4: А если в Zabbix выйдет что то, что дублирует функционал Glaber?

При равных параметрах реализации отдадим предпочтение майнлайну, то есть коду Zabbix, обеспечив механизм миграции.

Но пока это теория и за три года не было ни одного пересечения по новому функционалу Glaber и Zabbix.

Ссылки:

Прокет на gitlab: https://gitlab.com/mikler/glaber

Группа в телеграмме @glaber_group Можно писать мне лично в телеграмм @makurov или в почту makurov@glaber.ru