Введение

Glaber – это свободная система с открытым исходным кодом предназначенная для мониторинга ИТ сервисов и оборудования.

Glaber является форком популярной системы мониторинга Zabbix, он был создан в 2018 году. Историю и причины появления Glaber можно прочитать в истории проекта

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

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

Главной задачей Glaber является предоставление удобного доступа к оперативной информации, создание АРМ операторов мониторинга. Также
Основные возможности

Масштабируемая архитектура, основные компоненты

Сервер

Сервер это центральный элемент системы, отвечает за всю работу по мониторингу, обладает большой производительностью. С версии 3.2 сервер способен в устоявшихся режимах работы обрабатывать и сохранять более 500 тысяч метрик в секунду с существенным запасом.

Прокси сервер

Используется, в случаях, когда необходимо обеспечить «локальный» съем метрик, например, в удаленных локациях. Выполняет задачи по съему и предварительной обработке данных и передает данные на сервер. Позволяет решить проблему работы из NAT сетей.

Агенты

Работают на серверах, собирают локальные данные, а также могут выполнять действия по команде от системы мониторинга

Пользовательский интерфейс и API

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

Сбор данных

Система поддерживает активные (pull) и пассивные (push) методы сбора метрик. Сервер или прокси сервера могут либо сами выполнять запросы (pull-модель), либо работать в режиме серверов и «слушать» приходящие данные (push-модель).

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

Pull модель позволяет снимать данные в гарантированные промежутки времени с устройств, например, через протокол SNMP.

Поддерживаемые протоколы съема данных

Поддерживается около двух десятков стандартных протоколов:

SNMP, версии 1,2,3 в том числе с шифрованием, а также трапы
агенты
ODBC
IPMI
JMX
HTTP
TELNET
SSH
Кастомные скрипты
веб-сценарии
вычисляемые метрики
SYSLOG

Возможность расширения проколов пользователем

Существует возможность легкого расширения поддержки новых протоколов за счет применения модулей – воркеров

В случаях, когда требуется принять данные в формате, которые система не поддерживает «из коробки» можно сделать легкий модуль на любом языке, который принимает данные в любом формате и отдает их в Glaber в формате JSON.

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

Обработка данных

Препроцессинг данных

Существует несколько десятков типов обработки входящего потока данных, позволяющие: - обрабатывать Json данные - работать со строками и регулярными выражениям - управлять потоком данных и входной агрегацией данных - перенаправление данных в различные метрики по содержимому для входящей сортировки и структуризации

Автоматическое обнаружение метрик и объектов мониторинга

Для больших систем администрирование объектов вручную становится затратным, поэтому создание объектов мониторинга может быть автоматизировано за счет следующих подходов:

обнаружение сетевым сканированием : Система по диапазонам адресов сканировать сети и автоматически добавлять, а при необходимости, удалять неактуальные хосты. По выставленным признакам на хосты могут назначаться различные шаблоны
обнаружение компонентов : Используя собранные данные, система может автоматически создать объекты мониторинга, используя заранее определенные шаблоны. Типовое применение – определение типовых одинаковых компонентов в системах, например, порты, жесткие диски, пользователи на WIFI и так далее.
автоматическое создание метрик на основе входящего потока данных

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

Шаблоны

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

Шаблоны можно импортировать и экспортировать между системами, а также можно самостоятельно создавать и экспортировать свои шаблоны или исправлять существующие, в случае если это требуется.

Система реакции и оповещения на аномалии

Возможности реакции

Система может гибко реагировать на различные события. Помимо основных событий, когда наблюдаемые метрики вызывают срабатывание триггеров, существуют события, связанные с изменением состава объекта мониторинга и с функционированием мониторинга, что позволяет быстро, событийно реагировать на различные инциденты

Возможности триггеров

Триггеры поддерживают более трех десятков функций для вычисления условий, и булеву логику, что позволяет реализовывать сложные выражения

Кэш данных

Система помнит количество и глубину данных, которые необходимы для вычисления триггеров и хранит их в памяти, поэтому триггеры вычисляются очень эффективно. Один процесс может считать до 150 тысяч триггеров в секунду.

Cобытийная, мгновенная реакция на аномалии

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

Возможности эскалации

Существуют возможности гибкой эскалации проблем с различными условиями и задержками. Это позволяет реагировать не только на сами проблемы, но и управлять оповещение о ходе решения проблем, например, система эскалаций позволяет описать организационную логику и задать SLA по устранению инцидентов и при нарушении установленных правил эскалировать решение на более высокие организационные уровни предприятия.

Сервисная модель для отслеживания состояния сервисов

Существует возможность описывать деревья сервисов, чтобы определять работоспособность сервиса, а также видеть точку отказа или компонент, влияющий на работу сервиса. В том числе, существуют такие возможности:

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

Отчёты

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

Возможности оперативного мониторинга

Cистема дашбордов для создания кастомизированных специализированных АРМ операторов мониторинга

Дащборды могут быть созданы из более чем двух десятков различных виджетов. Система прав позволяет разграничить доступ к ним. Есть возможности много экранных дашбордов, а также режима работы «информационного табло» для стендов, стен, панелей, с отображением без лишних меню и элементов управления. Также можно создавать многостраничные дашборды с автоматической сменой отображения.

Интеграция с внешними системами

поддержка работы визуализации в Grafana Glaber, его состояние, метрики, могут отображаться в Grafana.
развитое АПИ для управления и получения информации об объектах системы, их состояниях, накопленных исторических и агрегированных метрик.

АПИ может использоваться для синхронизации объектов мониторинга с внешними системами. Также АПИ позволяет получить оперативные состояния объектов и накопленные исторические данные.

Доступ к системе

Гибкая система групп, хостов, аутентификации, позволяет разграничить доступ к различным частям системы и данным

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