Компоненты Astra Monitoring

Astra Monitoring состоит из следующих компонентов:

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

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

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

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

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

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

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

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

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

• agent — сервер, на котором устанавливается агент — приложение, выполняющее самостоятельную регистрацию в AM, поддерживающее удаленную настройку, сбор метрик/логов/сигналов с последующей отправкой на коллектор;

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

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

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

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

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

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

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

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

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

• Exporter 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) и отправляются в коллектор;

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

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

У каждого объекта может быть несколько интерфейсов. Объект считается активным в тот момент, когда на нем регистрируется хотя бы один интерфейс. Агент регистрируется автоматически при запуске, в то время как все другие интерфейсы должны быть добавлены вручную через 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 собирает метрики путем обращения к опубликованным на объектах мониторинга экспортерам и передает их далее на хранение в базу Victoria Metrics. Собранные в базе Victoria Metrics данные регулярно анализируются компонентом vmalert в соответствии с заданными правилами триггеров.

При обнаружении соответствия данных какому-либо правилу, vmalert отправляет сообщение в alertmanager с заданной в правиле информацией о сервере виртуализации, имени правила, его кратком и полном описании, критичности и о прочих сопутствующих тегах. В alertmanager события группируются, обрабатываются и далее отправляются по заданным каналам оповещениями командам поддержки, а также в базу данных платформы через am-injector и далее в интерфейс управления.

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

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

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

• 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. Также там хранятся события и лейблы.

Настройка агентов и коллекторов

Для удаленной настройки агентов и коллекторов используется сервис Config API. Он хранит данные в PostgreSQL и выполняет следующие функции:

• Установка. Для запуска агента ему необходимо предоставить бинарные файлы экспортеров, vmagent, vector, signals adapter. Чтобы не включать эти файлы в пакет поставки и тем самым не увеличивать его объем, агенту дана функция самому скачивать необходимые бинарные файлы с Config API.

• Регистрация. Агент отправляет регистрационный запрос в Config API при запуске, передавая информацию о сервере виртуализации, на котором запущен. Это позволяет автоматически добавлять объекты мониторинга. Достаточно запустить агент на нужной ноде и дальше с ним можно взаимодействовать удаленно.

• Конфигурация. Config API предоставляет конфигурацию агентам, позволяя удаленно влиять на процесс сбора диагностической информации. Например, в UI можно указать, какие экспортеры запускать, с каких SNMP-устройств получать трапы и так далее. При обновлении конфигурации создается новая запись в БД. Старая версия не удаляется, а помечается исторической — это позволяет отслеживать, как и когда менялась конфигурация.

• Получение информации. Config API принимает периодические запросы от агентов о статусе их работы. Агент сообщает информацию о состоянии каждого запущенного экспортера, предоставляет данные об ошибках.

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

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

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

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

Интерфейс пользователя

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

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

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

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

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