Обзор подсистемы мониторинга

Подсистема мониторинга (ПМ) — платформа сбора и анализа информации о состоянии узлов IT-инфраструктуры с целью их диагностики, своевременного обнаружения неполадок и повышения стабильности работы. Платформа масштабируема и может охватывать как несколько hardware устройств, например, с SNMP интерфейсом, так и географически распределенные сети с тысячами высоконагруженных нод.

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

Возможности подсистемы:

• сбор метрик, логов и сигналов с узлов IT-инфраструктуры;

• хранение диагностической информации в центре обработки;

• отображение собранной информации в панели администратора;

• создание событий при изменении состояний объектов наблюдения;

• оповещение пользователей по различным каналам связи.

Подсистема мониторинга состоит из следующих компонентов:

• клиентская часть;

• серверная часть;

• интерфейс пользователя.

Клиентская часть

Клиентская часть состоит из объектов мониторинга, на которые установлен набор различных экспортеров, в зависимости от роли, которую выполняют эти объекты.

Объект мониторинга

Объект мониторинга — источник диагностической информации. Информация о наблюдаемой подсети/локальной сети предоставляется только объектами мониторинга, которые зарегистрированы в ПM. Объект является отображением ноды/узла/сервера/устройcтва с уникальным FQDN/IP-адресом в рамках подсети/локальной сети. Для сбора данных с объекта используются его интерфейсы: сущности, описывающие правила получения и парсинга данных с источника, располагаемого на объекте.

Для сбора данных с Oбъекта используются его интерфейсы — сущности, описывающие правила получения и обработки данных с источника, располагаемого на Объекте. Количество используемых интерфейсов не ограничено. Получение метрик производится в соответствии с заданными критериями обработки входящих потоков данных.

Варианты интерфейсов:

• exporter — HTTP-сервер, предоставляющий метрики в prometheus формате;

• snmp-trap — устройство, отправляющее SNMP traps, в интерфейсе описаны правила парсинга приходящего трапа;

• snmp-poll — устройство, предоставляющее порт для сбора информации по протоколу SNMP, в интерфейсе описаны правила парсинга;

• ipmi — IPMI устройство;

• http — произвольные HTTP запросы (обычно с JSON в теле), для которых определены правила парсинга в сообщение.

Интерфейс agent (Агент)

Агент — основной компонент сбора и предоставления диагностической информации в рамках отдельного сервера/хоста. Технически, агент является оркестратором процессов — он запускает экспортеры и vmagent для сбора метрик, vector для сбора логов, Signals Adapter для сигналов. Агент выполняет наблюдение за их состоянием и исправление возникающих проблем. Агент автоматически регистрируется в ПM, предоставляя информацию о наблюдаемом сервере виртуализации.

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

• Exporters Manager — отвечает за запуск экспортеров в отдельных процессах ОС, за их контроль и настройку. Экспортер — приложение, собирающее информацию и представляющее ее в виде prometheus метрик. Обычно запускается несколько экспортеров, так как каждый отвечает за сбор информации только о конкретном продукте или части системы. Например, systemd-exporter предоставляет метрики только о работе systemd, node-exporter — общую информацию об ОС, и так далее;

• Metrics Manager — настраивает и запускает vmagent для сбора метрик с экспортеров. vmgent потребляет мало ресурсов, при этом способен собирать метрики с огромного количества источников, модифицировать лейблы и локально кэшировать собранные данные при недоступности AM Backend. Помимо экспортеров, запущенных Exporter Manager, vmagent на агенте может собирать метрики с любого другого экспортера при соответствующей настройке;

• Logs Manager — настраивает и запускает vector для сбора логов. Он поддерживает большое количество источников и способен трансформировать логи перед отправкой, а также сохранять в локальном буфере при ошибках отправки. Кастомизация и сбор логов с произвольных источников выполняется путем предоставления сторонних файлов конфигурации для vector;

• Signals Manager — настраивает и запускает Signals Adapter для получения сигналов. Адаптер использует два сервера — UDP для приема SNMP-traps и HTTP, представляющий API для загрузки сигналов со сторонних клиентов. Сигналы обрабатываются на основе настраиваемых правил (актуально для SNMP) и отправляются в коллектор;

• Proxy Manager — настраивает и запускает vmauth для агрегации всех входящих на агент запросов от других агентов. Это опциональная функция, так как агент может взаимодействовать с бэкендом напрямую. Каждый агент отправляет запросы к Config API, которые в данном случае проксируются vmauth на бэкенд. Также агенты присылают диагностическую информацию, которая сначала собирается в vmagent, vector и Signals Adapter на проксирующем агенте, а затем отправляется на бэкенд / следующий прокси;

• Watcher & Configurator — контролирует взаимодействие с Config API, расположенном на AM Backend. Выполняет регистрацию при запуске, позволяет удаленно настраивать агент, предоставляет информацию о работоспособности всех его модулей;

• Server — HTTP-сервер, который используется для предобработки логов от vector перед отправкой в бэкенд и для healthcheck запущенного агента.

Другие интерфейсы

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

Коллектор для диагностической информации

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

Как и агент, коллектор состоит из внутренних модулей:

• Exporter Manager — настраивает и запускает snmp-exporter для общения с hardware устройствами по SNMP и ipmi-exporter для сбора метрик с удаленных устройств IPMI;

• Metrics Manager — настраивает и запускает vmagent для агрегации метрик с агентов. Способен кэшировать метрики при недоступности AM Backend, используется для добавления лейблов. Обеспечивает возможность наблюдения сторонних объектов мониторинга типа exporter и сбора метрик с локальных SNMP и IPMI exporters;

• Logs Manager — настраивает и запускает vector для агрегации логов с агентов. Способен трансформировать проходящие данные и обогащать логи дополнительной информацией, Также ведет сбор логов с подсистем коллектора;

• Signals Manager— настраивает и запускает Signals Adapter для получения сигналов. Работает так же, как и на агенте, но дополнительно получает запросы от других адаптеров для агрегации и последующей отправки на AM Backend. Используется для добавления в сигналы недостающих лейблов и приема сигналов на стороне коллектора;

• Proxy Manager — настраивает и запускает vmauth для агрегации всех входящих на коллектор запросов от агентов. Каждый агент отправляет запросы к Config API, которые проксируются vmauth на AM Backend. Также агенты присылают диагностическую информацию, которая сначала собирается в vmagent, vector и Signals Adapter на коллекторе, а затем отправляется на AM Backend;

• Watcher & Configurator — контролирует взаимодействие с Config API, расположенном на AM Backend. Выполняет регистрацию при запуске, позволяет удаленно настраивать коллектор, предоставляет информацию о работоспособности всех его модулей.

Примечание

Пример

На сервер контроллера домена могут быть установлены node-exporter, systemd-exporter, freeipa-exporter и агент vector для сбора логов, а на узел виртуализации ПВ — node-exporter, systemd-exporter, агент vector и libvirt-exporter. Установленные экспортеры собирают доступные им метрики, в зависимости от назначения экспортера, и публикуют их, используя специфичный для конкретного экспортера порт, например, <host_address>:9100/metrics для freeipa-exporter.

Компоненты клиентской части:

• набор «Экспортеров». Обеспечивают сборку метрик и статистик наблюдаемой системы (загрузка CPU, ОЗУ, загрузку сетевых интерфейсов и т.д.);

• программный продукт «Vector». Обеспечивает обработку и отправку логов в систему Astra Monitoring.

Серверная часть

Компоненты серверной части:

• Prometheus — обеспечивает сбор метрик со всех совместимых систем и сервисов;

• Vector.dev — принимает и обрабатывает лог-файлы с помощью компонентов Vector агента и сервера, который осуществляет запись полученных данных в базу данных на основе Clickhouse. Архитектура передачи данных «Vector — Vector» позволяет масштабировать систему доставки логов на сложные конфигурации дочерних подразделений;

• Victoria Metrics — обеспечивает прием метрик с объектов наблюдения, которые сохраняются в базу данных Victoria Metrics;

• Clickhouse — обеспечивает хранение данных в СУБД и за счет сжатия они занимают меньше места, чем сырые данные. Логи категоризируются по уровню критичности события и все записи с низким уровнем критичности (info, debug, trace) помещаются в базу данных Info Logs, а записи с высоким уровнем критичности (warning, critical, error) помещаются в базу данных Critical Logs;

• PostgreSQL — система управления базой данных, которая отвечает за хранение объектов наблюдения, информации о событиях объектов мониторинга;

• AlertManager — сохраняет информацию о событиях в БД PostgreSQL через AM-Injector. Реализует отправку уведомлений о событиях в соответствующие информационные каналы (Email, Telegram, Mattermost).

Управление ПО AM производится через Web-интерфейс, или интерфейс командной строки.

Получение данных

Для взаимодействия с коллектором AM Backend предоставляет HTTP(S) API. Технически, это API Gateway, который распределяет запросы по нужным микросервисам в зависимости от пути HTTP запроса. AM Backend и коллектор могут располагаться как в одной локальной сети, так и в разных. Коллекторов, работающих с одним AM Backend, может быть несколько. Их количество ограничено только доступными ресурсами. В качестве API используется vmauth — решение для балансировки нагрузки из экосистемы Victoria Metrics, которое обладает простой установкой и конфигурацией.

Хранение данных

Victoria Metrics: хранение метрик

Victoria Metrics — NoSQL база данных, специализированная для эффективного хранения метрик и временных рядов. Она используется для полной замены Prometheus из-за явных недостатков последнего при росте объема хранимых данных. VM предоставляет язык запросов MetricsQL, который является расширением языка PromQL и используется для получения и агрегирования метрик. Также эта БД способна горизонтально масштабироваться, что позволяет использовать ее для хранения и обработки огромного объема данных.

Метрики в Victoria Metrics попадают напрямую из vmauth.

ClickHouse: хранение логов и сигналов

ClickHouse — NoSQL база данных колоночного типа, специализированная для эффективного хранения огромных объемов данных различной природы. Основная сфера применения — OLAP (Online analytical processing) запросы, целью которых является анализ данных, создание отчетов, графиков и дашбордов. База данных имеет свой SQL-подобный язык запросов с широким функционалом, способна горизонтально масштабироваться.

Логи и сигналы сначала попадают в микросервис ClickHouse Adapter. Этот сервис предоставляет API для записи данных в ClickHouse — преобразует пришедший JSON в поля SQL запроса и формирует батч.

PostgreSQL: хранение внутренних сущностей

PostgreSQL — реляционная база данных, обладает широким функционалом и поддерживает JSON, что сильно облегчает задачу хранения внутренних сущностей.

Внутренние сущности — данные, которые не относятся непосредственно к диагностической информации. В основном, это конфигурация различных компонент — объектов мониторинга, коллекторов, Event Processor. Также там хранятся события и лейблы.

Состояния наблюдаемых объектов

AM предоставляет два варианта получения информации о наблюдаемом объекте — состояние и события. Состояние представляет из себя диагностическую информацию в «сыром» виде, в то время как события — сгенерированные на основе этой информации сущности, необходимые для оповещения о наступлении определенных состояний.

События о наблюдаемых объектах

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

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

Компоненты:

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

• интерфейс управления — Admin UI. Предназначен для добавления объектов мониторинга, а также для просмотра информации о событиях по объектам мониторинга;

• Keycloak — обеспечивает аутентификацию пользователей, поддерживает интеграцию с внешними системами аутентификации и каталогами пользователей (LDAP).

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