# Структура MONQ

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

# Состав модулей

Программное обеспечение MONQ состоит из следующих частей:

  • Модуль приёма и предварительной обработки данных из систем мониторинга
  • Модуль расчета статусов
  • Модуль реагирования
  • Модуль организации хранилища данных
  • Инфраструктурный модуль
  • Модуль функционального тестирования FMONQ
  • Ресурсно-сервисная модель
  • Публичный REST API
  • OAuth2.0 + OpenId
  • Пользовательский интерфейс

Изображение

# Модуль приёма и предварительной обработки данных

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

# Модуль расчета статусов

Модуль отвечает за обработку получаемых сообщений, создание правил синтетических триггеров с помощью скриптов на языке Lua, расчёт статусов триггеров по созданным правилам и расчет статусов КЕ по статусам активных СТ.

# Модуль реагирования

Модуль реагирования состоит из подмодулей Правила и действия и Мои скрипты.

Правила и действия позволяет пользователям задавать правила обработки событий изменения статуса СТ, а также конфигурировать действия а качестве реакции на выполненные правила. В качестве действий можно назначить операции оповещения пользователей по электронной почты и мессенджерах, регистрации инцидентов в системах ServiceDesk и выполнения скриптов, поддерживающих запуск cURL, SMTP, SNMP, SSH и команд языка Lua.

# Модуль организации хранилища данных

Модуль организации хранилища данных – СУБД ClickHouse хранит поступающие извне события, а компонент управления коннекторами проверяет доступность активных коннекторов, очищает хранилища от неактуальных данных и собирает новые поступающие данные.

# Инфраструктура

Инфраструктурная часть MONQ, наряду с описанием СПО, включает несколько подмодулей:

  • Модуль общесистемных настроек – содержит набор сервисов, которые отвечают за настройки экземпляра ПО, не связанные с непосредственной обработкой событий:
    • Сервис управления пользователями и рабочими группами.
    • Система хранения и управления настройками экземпляра MONQ – настройки визуальной части (иконки, надписи, стили), системные настройки (доступ к БД для микросервисов, уровень логирования).
  • Модуль хранения и обработки логов действий пользователя.

# Модуль функционального тестирования FMONQ

FMONQ содержит API приёмника отчетов о выполнении сборок функционального тестирования, парсер для преобразования отчетов в модель FMONQ, API для управления проектами ФТ и хранения метаинформации. В денормализованном виде, сборки хранятся в БД ClickHouse. Интеграция в части триггерной модели осуществляется с помощью Zabbix.

# Ресурсно-сервисная модель

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

# Публичный API

Публичный API – позволяет взаимодействовать с ПО без веб-интерфейса, используя программный интерфейс HTTP REST API.

# OAuth2.0 + OpenId

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

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

Веб-интерфейс для взаимодействия пользователя с программным обеспечением.

# Взаимодействие модулей

В целом, набор модулей и принцип их взаимодействия можно разделить на 2 типа:

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

Источником данных MONQ служат системы и инструменты мониторинга или логирования, отслеживающие необходимые метрики и генерирующие первичные события. Такими метриками могут быть в том числе и ошибки выполнения сценариев функционального тестирования модуля FMONQ.

Модуль приёма и предобработки данных получает данные из источников в формате JSON и преобразует их в структуру данных – интегральные события, используемые в MONQ. Предобработанные события затем помещаются в хранилище на базе СУБД ClickHouse.

Далее данные поступают на обработку в модуль расчета статусов: если среди синтетических триггеров находится такой, под чей префильтр подходит полученное событие, происходит расчет статуса триггера в соответствии с правилом, реализованном внутри триггера на языке Lua и формируется событие внутри MONQ. Если триггер привязан хотя бы к одной конфигурационной единице, происходит перерасчет режима работы КЕ соответственно статусу СТ.

Каждое новое событие проверяется модулем реагирования на соответствие условиям (Правилам), заданным пользователями. Если событие подходит под необходимые условия, происходит запуск привязанного к Правилу Действия – набора операций, нацеленного на устранение инцидента, оповещение заинтересованных или ответственных лиц, запуск скрипта самолечения и т.п.

Как только из первичной системы мониторинга поступает сообщение о завершении события – событие завершается и в MONQ, что также может быть обработано модулем реагирования. Для некоторых типов интеграций (Zabbix, SCOM, vCenter) разработаны специальные задания по получению событий из API или напрямую из БД и отправку полученных событий в модуль приёма и предварительной обработки событий. Такие задания выполняются с заданной периодичностью и настраиваются непосредственно в БД MONQ по типам интеграций.

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

Доступ пользователей к ПО контролируется сервисом обеспечения безопасности (OAuth2.0, OpenId), а доступ к объектам и разделам ПО – модулем общесистемных настроек, хранящий информацию о принадлежности пользователя к той или иной рабочей группе в той или иной роли, наличии у данной РГ или роли достаточных прав. Модуль хранения и обработки логов также хранит историю действий пользователя.

Все пользовательские действия совершаются в графическом веб-интерфейсе ПО, который посредством API передаёт команды на сервер.