В нашем блоге мы много говорили об иностранных решениях для мониторинга и аудита, и вот пришло время для отечественной разработки. MONQ — зонтичная система с коннекторами для распространённых систем мониторинга, ресурсно-сервисными моделями, анализом данных, высоким потенциалом к AI и особенной моделью лицензирования. Нам выдали дистрибутив на посмотреть и мы решили поделиться как оно там под капотом и всё ли так нанотехнологично как говорит вендор (проект, всё-таки, резидент Сколково). Честь потестить выпала мне и я тут расскажу про установку, возможности системы и немного про лицензирование. Прошу под кат.

Введение

В 2018 году Gartner ввел новый термин для описания того, каким образом искусственный интеллект (ИИ) может быть применен к поддержке ИТ. «AIOps (Artificial Intelligence for IT Operations) обещает cэкономить время и усилия ИТ-служб, затрачиваемые на выявление различных неполадок во все более сложной среде, в которой им приходится работать». Gartner предполагает, что ИИ будет применяться для автоматической идентификации возникающих проблем и их устранения. В 2019 году это кажется сказкой, и никаких реальных кейсов полностью автоматической поддержки ИТ я пока еще не видел.

Мне в руки попала платформа MONQ от MONQ Digital lab. Сам разработчик позиционирует ее как AIOps решение. Но я бы назвал ее все же системой зонтичного мониторинга, управления событиями и запуска скриптов автоматизации. Интеллекта пока в ней не так много.

По долгу службы я поддерживаю более 100 разных систем, серверов, служб, сервисов. Мой casual-инструментарий для мониторинга — Zabbix и Prometheus, т.к. они закрывают большую часть задач контроля производительности. Пара систем в контуре мониторинга иногда перестают отвечать, лечится это перезагрузкой сервера (по-другому там никак, переписывать кривой код уже никто не будет). Всегда хотел попробовать реализовать кейс, когда система мониторинга выявляет проблему из двух независимых источников и сама перезапускает сервер. Для таких задач обычно применяют зонтичные системы с подсистемами запуска скриптов, как это сейчас модно называют RPA (Robotic Process Automation). Бесплатных систем я не знаю, а коммерческие стоят как чугунный мост.

Сегодня мы попробуем вместе установить MONQ, подключить к ней Zabbix и Prometheus, настроить оповещения и написать скрипт перезагрузки сервера. Чтобы завтра можно было спокойно закинуть ноги на стол, лишь изредка наблюдая за процессом лечения одной машины другой машиной и попивать кофе с круассаном.

Архитектура решения

Архитектура MONQ

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

Распаковка

На Youtube полно видео с распаковкой чего-либо. Сейчас попробую сделать то же самое, но в текстово-картиночном формате и не с физическим товаром, а дистрибутивом. Для начала подготовка — установка кластера kubernetes.

Про настройку кластера kubernetes можно почитать, например, здесь. Я же расскажу про особенности настройки:

• в качестве кластерного DNS используется coredns;
• nginx-ingress-controller;
• rbac авторизация в кластере;
• используется общий storage (pv/pvc).

Для каждого проекта вендор предоставляет технические требования к аппаратному обеспечению. Минимальная конфигурация для установки — 4 сервера. Этого достаточно для проведения пилота при условии интеграции с одной системой мониторинга. Для моих целей проверки функционала системы такой вариант тоже сгодится.

В боевых условиях, как мне сказали, система масштабируется под запросы заказчика в зависимости от нагрузки и требуемой отказоустойчивости.

Моя конфигурация для системы на минималках:

После того, как платформа подготовлена, запускаю вендорский ansible playbook для установки базовой инфраструктуры и запуска системы. Playbook делает следующее:

• устанавливает необходимые пакеты на серверах;
• запускает kubernetes;
• устанавливает и настраивает приложения на сервере БД. Среди них: Clickhouse, RabbitMQ, PostgreSQL, ArangoDB, Redis и всё это в docker-контейнерах;
• устанавливает Consul для централизованного хранения конфигураций микросервисов;
• добавляет сущности endpoint, service ingress для СУБД и инфраструктурных частей системы;
• генерирует таблицу с авторизационными данными.

Чтобы не запускать микросервисное приложение вручную, вендор подготовил встроенный реестр микросервисов, который добавляет и обновляет микросервисы, конфигурирует СУБД и межсервисную авторизацию.

Запуск системы сводится к следующим действиям:

• запускается инсталлятор системы с предварительно подготовленным конфигурационным файлом (в нем содержатся авторизационные данные в kubernetes, СУБД и Consul, доменное имя системы);
• инсталлятор запускает реестр микросервисов;
• с помощью реестра микросервисы поочередно запускаются, реестр генерирует конфигурацию микросервисов в consul, сущностей deployment, service, ingress в kubernetes;
• при старте каждый микросервис загружает схему для собственной БД.

Результат работы инсталлятора, который я запустил, на картинке ниже.


Дашборд kubernetes: результат работы инсталлятора

После завершения процесса установки MONQ будет доступен по доменному имени, который я указывал в конфигурационном файл инсталлятора. А вот и он.


Интерфейс входа в MONQ

Настройка

В стартовой настройке системы уже есть пользователь с полными правами на управление. Авторизуюсь под ним и посмотрю на что способен MONQ.

Создание пользователей в системе и настройка рабочих групп

В системе есть две методики авторизации пользователей:

• Active Directory;
• Встроенная.

Для первого знакомства подойдёт встроенная авторизация.


Предустановленный пользователь Системы

Права доступа к объектам и ресурсами системы (интеграции, конфигурационные единицы (КЕ), синтетические триггеры, скрипты и т.д.) выдаются на уровне рабочих групп (РГ). Любая РГ может быть владельцем объекта либо иметь права на чтение или запись. Есть несколько уровней доступа:

• Члены РГ с уровнем прав владельца могут выполнять с объектом любые действия (РГ с таким уровнем прав у объекта может быть только одна);
• РГ с правом на запись может управлять объектом, но не может его удалить и раздать на него права другим РГ;
• РГ с правом на чтение может просматривать информацию по объекту;
• РГ без права доступа к объекту вообще не в курсе о его существовании.

По умолчанию в системе уже создана РГ «Администраторы пространства», в которой как раз и обосновался мой пользователь. У этой РГ полные права на все объекты, которые будут созданы в этой сущности. Для коллег, которые тоже захотят взглянуть на систему, создал дополнительную РГ «Супер администраторы».


Рабочие группы, роли и участники

Права конкретных пользователей настраиваются в рамках РГ в виде ролей.

Настройка РСМ

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

Основным отличием и, на мой взгляд, преимуществом воплощения РСМ в системе является ориентация на бизнес-сервисы. Это помогает представить полную структуру услуги или сервиса, которым пользуется конечный потребитель, а не ориентироваться на инфраструктурную систему, на которой базируется данная услуга или сервис.

Для целей тестирования сделал упрощенную РСМ «Личный кабинет пользователя».


РСМ «Личный кабинет пользователя»

После настройки мониторинга покажу как она преобразится.

Состав РСМ:

• Виртуальная машина, на которой крутится информационная система (ИС) SRVe3_VM15;
• СПО: Nginx_LK, PHP-fpm_LK, MySQL_LK;
• Наш сервис (ИС) — LK (личный кабинет);
• Модули ИС: Авторизация, Поиск, Документооборот, Оплата. На самом деле их больше, но пока создал только эти.

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

В MONQ доступно подключение систем различных типов:

• Системы мониторинга (Zabbix, Prometheus, SCOM и другие);
• Системы сбора логов (Splunk, Logstash и другие);
• Системы запуска автотестов (Jenkins, Gitlab CI и другие)
• Сервис-дески, таск-трекеры (Microfocus SM, Jira, Redmine, Naumen и другие).

Я подключил системы мониторинга Zabbix, Prometheus. Эти коннекторы настраиваются в разделе «Интеграции».


Интеграции с системами мониторинга

Из Zabbix и Prometheus в MONQ приходят метрики и события.

Подключение синтетического мониторинга (автоматизированное функциональное тестирование)

В MONQ можно также настраивать функциональное тестирование приложений. В моём примере это личный кабинет. Я подключил несколько сборок автотестов из Jenkins.


Модуль функционального мониторинга “FMON проекты”

Функциональный мониторинг в MONQ — это отдельный модуль с собственным экраном «Функциональное тестирование». А вот пример отчета о выполнении одного из моих тестов:


Проект FMON «Авторизация пользователя», проваленная сборка

Настройка мониторинга и оповещений

По стандартным шаблонам (из коробки доступны несколько готовых шаблонов для синтетических триггеров для каждой интеграции) создал синтетические триггеры по первичным событиям из Zabbix и Prometheus. Синтетическими триггерами здесь называются триггеры, созданные внутри платформы, которые работают с первичными данными из разных источников. Дальше я привязал получившиеся триггеры к элементам (КЕ) РСМ.


Раздел «Синтетические триггеры»

А так выглядит синтетический триггер созданный по шаблону.


Пример синтетического триггера созданного по шаблону для Prometheus

В разделе «Мои скрипты» для примера уже есть скрипт, который перезагружает сервер. Сам скрипт написан на Lua и его можно изменить. На его основе я сделал собственный скрипт для перезагрузки сервиса.


Скрипт перезагрузки сервиса на сервере

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

Для использования интеграций с мессенджерами нужно открыть доступ в облако Microsoft Azure.

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


Плагин отправки СМС для платформы MONQ

Визуализация мониторинга

После настройки моя РСМ немного видоизменилась, на общий мониторинг были вынесены еще три системы, от состояния которых зависит работоспособность ИС «Личный кабинет пользователя». Также сюда добавлены несколько сервисов.


РСМ «Личный кабинет пользователя» с привязанными триггерами

Общая информация о состоянии объектов на мониторинге выведена на основное представление в форме настраиваемых виджетов.


Основное представление для ИС «Личный кабинет пользователя»

На момент снятия скриншота наблюдается проблема с большим количеством запросов в БД, из-за чего увеличился отклик страниц в ИС «Личный кабинет пользователя». Об этом система информирует на экране и отправляет смс.

Для оперативного мониторинга используется «Оперативный экран» на котором всего один виджет с актуальным на текущий момент списком событий (активные события и события, которые закрылись 15 минут назад).


Представление «Оперативный экран»

Для тестирования сгенерировал высокую загрузку на CPU виртуальной машины при помощи MySQL. Система отловила событие и запустила действие с заранее подготовленным скриптом перезагрузки сервиса mysqld. Если через 15 минут событие будет еще активно, то произойдет перезагрузка.


Сервис штатно перезагрузился, а мне пришло оповещение, что все ОК.

Все события во времени можно посмотреть в разделе «Шкала времени». А если еще подключить ITSM систему, то на ней будут отображаться работы, которые запланированы по данным КЕ.


События мониторинга на представлении «Шкала времени»

Информацию о доступности систем, которые были установлены на мониторинг можно смотреть в представлении «Отчеты SLA».


Отчет SLA по ИС «Личный кабинет пользователя»

Для наглядности сформировал отчет за две недели исключив из него события с приоритетами 3 и 4, ну, и тестовые, разумеется. Если верить отчету, система работает отлично. Отчет экспортируется в PDF и XLS.

Экраны показывают информацию по фильтрам, которые предварительно настраиваются пользователем. Любое событие на экранах можно отметить тегом для его быстрого поиска или фильтрации.

Лицензирование

Нефункциональное, но от того не менее ключевое преимущество MONQ я приберег для конца статьи. Это лицензирование. Абсолютное большинство иностранных решений зонтичного мониторинга лицензируются по количеству устройств (называется обычно per endpoints, per OS Instance или как-то ещё), от которых обрабатываются события или метрики. Вне зависимости от того, собираете ли вы ими данные с конечных объектов мониторинга, или это делает другая система мониторинга. Если сбор метрик выполняется при помощи коммерческой системы — двойная оплата за одно и то же неизбежна. MONQ лицензируется по количеству используемых коннекторов к внешним системам. То есть, если у вас используется две системы, откуда вы хотите собирать информацию — это два используемых коннектора или две лицензии. Таким образом, с точки зрения «платы за сбор», при использовании MONQ ничего не изменится. Вы оплатите только стоимость интеграций с этими системами. В этом я вижу большое преимущество и потенциал.

Как мне сказали, в планах развития системы множество улучшений, которые внедряются постоянно. Из заметных новшеств в ближайшие полгода появятся: конструктор дашбордов, мастер создания синтетических триггеров, повышение детализации при расчёте SLA (будет видно какой фактор и насколько повлиял на доступность объекта) и внешнее публичное API.

Выводы

Мне понравилось, что ребята из компании разработчика легко идут на контакт, рассказывают и делятся информацией, да и система понравилась. В ней ещё не так много функциональных возможностей и пока тяжело напрямую сравнивать со Splunk или AppDynamics в части AIOps, но, однозначно, если все о чем они говорят воплотится в реальность, эта система займет достойное место в ряду лидеров рынка и квадранта Gartner.

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