История

В начале 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 и шаблонов позволяют настроить системы, где можно просто «лить» данные на сервер мониторинга, при этом все необходимые объекты сервер создаст сам по шаблонам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Glaber cluster

Glaber может работать в режиме кластера, распределяя нагрузку между серверами. Если один из серверов выходит их строя, то оставшиеся перереспределяют его наргрузку. Для работы кластера я придумал концепцию «доменов мониторинга" - нового способа настройки и способа взаимодействия серверов в кластере.

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

Cущественным ограничением до сих пор является наличие SQL базы c большим количеством апдейтов и общее усложнение системы. Для корректной работы кластера необходимо обеспечить синхронизацию SQL баз, что иногда бывает нетривиальной задачей.

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

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

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

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

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

Q1: Частый вопрос, который мне задают пользователи Glaber: ”вот тебя в гугл схантят и ты бросишь проект, чего нам делать"?

Мне очень нравится проект и вопрос развития Glaber это скорее вопрос смысла и мотивации. Я не зацикливаю развитие Glaber на себе и понимаю, что должно быть комьюнити, команда. Поэтому активно смотрю и ищу людей в команду. Сейчас Glaber поддерживается несколькими компаниями.

Q2: Это же opensource?

Да, на гитлабе можно скачать исходники. https://gitlab.com/mikler/glaber. Там же есть инструкции по установке на Debian и RedHat-based системы

Q3: А сложно ли поддерживать самостоятельно Glaber?

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

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

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

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

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

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

Немного ссылок, явок и паролей:

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

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