СофтХабрахабр

MONQ — мониторинг и AIOps родом из России

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

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

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

Мой casual-инструментарий для мониторинга — Zabbix и Prometheus, т.к. По долгу службы я поддерживаю более 100 разных систем, серверов, служб, сервисов. Пара систем в контуре мониторинга иногда перестают отвечать, лечится это перезагрузкой сервера (по-другому там никак, переписывать кривой код уже никто не будет). они закрывают большую часть задач контроля производительности. Для таких задач обычно применяют зонтичные системы с подсистемами запуска скриптов, как это сейчас модно называют 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 минут назад).


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

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


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

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


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

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


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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть