Новый Monq 8.0 – российский all-in-one мониторинг на low и no code автоматизации: обзор возможностей и «невозможностей»
Оперативный центр в Monq
Привет, Habr!
Последние несколько лет мы активно строили зонтичный мониторинг и здорово в этом преуспели. Теперь у нас новая задача — построить лучший комплексный мониторинг на рынке РФ. С версией 8.0 Monq становится all-in-one мониторингом, который покроет максимум мониторинговых задач в крупных компаниях. Это самый крупный релиз за последнее время. Рассказываем, что теперь может платформа.
(Может показаться, что это тип статьи, при прочтении которых у участников сообщества возникает мысль — «Опять рекламируют свой продукт, никакой пользы». Правда, наша статья отличается двумя особенностями. Во-первых, мы предупреждаем сразу, что, действительно, речь про обзор функционала от вендора, но — обещаем — здесь не будет прилагательных в превосходной форме. Во-вторых, расскажем и о том, чего Monq не умеет).
Продолжайте читать, если отвечаете за мониторинг, доступность цифровых сервисов, эксплуатацию, страдаете от «шторма алертов», ищете замену западным решениям и хотите навести «порядок в зоопарке» своего ИТ-окружения.
В этой статье расскажем:
об истории продукта;
о текущем функционале Monq и решаемых задачах;
о модуле зонтичного мониторинга, включая карты здоровья и построение ресурсно-сервисных моделей;
о модуле синтетического мониторинга, включая мониторинг пользовательских интерфейсов и веб-сервисов;
о том, как реализован мониторинг инфраструктуры в системе;
о модуле low и no-code автоматизации;
о возможных интеграциях.
Кратко — как всё было
Вместо лишних слов — просто схема развития продукта c 2015 года и один комментарий: этот путь наглядно отражает развитие от зонтичного мониторинга к all-in-one платформе, которая покроет большинство задач мониторинга и автоматизации в крупных и средних компаниях.
Таймлайн развития платформы
Важно: all-in-one не означает отказа от зонтика, а дополняет и развивает его. Это значит, что те пользователи, которые хотят интегрировать в Monq свои системы мониторинга, смогут делать это и дальше, а если какого-то функционала не хватает — пользоваться модулями из «коробки» платформы, которых с каждым релизом будет всё больше.
Какой Monq сегодня?
Monq 8.0 — это платформа all-in-one мониторинга, которую можно гибко настраивать с помощью low no-code автоматизации. Платформа охватывает большинство задач мониторинга и эксплуатации в сложных и разрозненных ИТ-окружениях, помогает управлять состоянием инфраструктуры и бизнес-сервисов и и проактивно реагировать на сбои. Monq предоставляет только важную информацию о состоянии цифрового ландшафта, учитывает влияние состояния элементов ИТ-окружения на стабильность работы бизнеса и помогает быстро увидеть первоисточник проблемы и ускорить расследование инцидентов.
Прежде всего, система нужна крупным компаниям со сложными окружениями и инфраструктурами — в небольших компаниях такой мониторинг может быть излишним. Именно поэтому добавим, что пока речь идет про мониторинг enterprise-уровня (хотя некоторые функциональные блоки, например, тот же мониторинг Kubernetes, может найти полезным каждый инженер — о нём будет ниже). А вот с выходом Saas-версии платформы в ближайшее время, ростом числа готовых контент-паков и уже вышедшей no-code автоматизацией Monq станет мониторингом и для малого и среднего бизнеса.
Ремарка для «импортозамещающих» — Monq находится в Реестре Минцифры, сертифицирован ГК «Астра» и может заменить такие западные продукты, как Splunk, Micro Focus, Solar Winds, IBM и др.
А что такое «all-in-one мониторинг»?
Аll-in-one мониторинг — это подход к управлению в ИТ, который объединяет в себе всевозможные инструменты и решения для мониторинга различных аспектов ИТ-окружения в единой системе. Такие системы обычно предоставляют возможности мониторинга для различных компонентов ИТ-окружения — инфраструктуры, приложений, бизнес-сервисов. Кроме того, они также могут предоставлять инструменты для анализа данных, создания отчётов, оповещений о проблемах и автоматизацию для управления задачами эксплуатации. Преимущества такого подхода включают в себя удобство централизованного управления, уменьшение сложности и издержек на интеграцию различных инструментов, а также повышение эффективности операций мониторинга и управления ИТ-инфраструктурой в целом.
Monq обладает всеми этими характеристиками. Обзорно доступный из «коробки» функционал представлен на схеме:
Функциональные модули Monq
Далее кратко рассказываем про каждый функциональный блок — какие задачи он решает и как устроен (конечно, каждый из них требует подробной отдельной статьи — они будут выходить в нашем блоге поэтапно).
Зонтичный мониторинг
Зонтичный мониторинг — это подход, при котором весь комплекс приложений и инфраструктуры охватывается одним централизованным инструментом для получения комплексного представления об ИТ в связке с бизнес-сервисами и ИТ-услугами. Такая централизация позволяет быстро выявлять и устранять проблемы, оптимизировать производительность систем и повышать общую надежность. Кому нужен и не нужен зонтик — объясняли в этой статье.
Комплексное представление данных в Monq обеспечивает единое окно мониторинга — Оперативный центр. Оперативный центр предоставляет пользователям полную информацию как о каждом конкретном объекте мониторинга (или конфигурационной единице, КЕ), так и об их связях и влиянии друг на друга.
Оперативный центр в Monq как единое окно мониторинга
CMDB и ресурсно-сервисная модель (РСМ)
Ресурсно-сервисная модель (РСМ) — это логическая модель ИТ-сервиса, описывающая состав и взаимодействие ресурсов, которые совместно обеспечивают предоставление данного сервиса на согласованном уровне.
В Monq РСМ имеет графовое представление, а информация о сервисах и их ресурсах (в обоих случаях это конфигурационные единицы) хранится в собственной CMDB.
Особенность РСМ в Monq — в ориентации на бизнес-сервисы. Такой подход позволяет представить полную структуру услуги или сервиса, с которым сталкивается конечный потребитель (и от доступности которого зависят финансовые показатели компании). Это важное отличие от других подходов, ориентированных на инфраструктурную систему.
Наполнение CMDB данными и построение РСМ может проходить как в ручном режиме, так и в автоматическом, по данным из различных информационных систем, подключаемых к Monq, — локальных разрозненных CMDB, ITSM-систем, различных систем управления конфигурациями, виртуализацией, контейнеризации др.
CMDB в платформе организована на ArangoDB и позволяет определить абсолютно любой состав типов конфигурационных единиц. Для каждого типа можно настроить:
атрибутивный состав — набор обязательных параметров, который будет у каждой КЕ данного типа;
компонентный состав — составляющие части КЕ для расчета показателей здоровья и покрытия мониторингом;
параметры расчета здоровья для каждого компонента;
слоты обязательных элементов мониторинга (метрик) для каждого компонента для расчета показателя покрытия мониторингом;
правила расчета статуса КЕ.
Такой подход позволяет описать произвольную РСМ соответствующую требованиям заказчика.
Ресурсно-сервисная модель в Monq
CMDB в Monq
Режимы обслуживания
Кроме основной информации о конфигурационных единицах и их атрибутивном составе Monq позволяет собирать и обрабатывать информацию об их особом состоянии — режимах обслуживания. Эта информация может быть получена из внешних систем как из первоисточников, либо режимы обслуживания могут быть запланированы непосредственно в Monq. Информация о режимах обслуживания может быть использована при подготовке отчетов, выполнении автоматических действий, например, отправки оповещений или регистрации инцидентов.
Режимы обслуживания в Monq
Покрытие мониторингом КЕ
Если показатель здоровья КЕ дает пользователям представление о ее состоянии, то показатель покрытия мониторингом дает понимание, насколько хорошо ведется наблюдение за конфигурационной единицей. Ведь никто не застрахован от случая, когда здоровье КЕ — 100%, ее статус — «Ок», но по ней не отслеживается ни один показатель.
Покрытие мониторингом в платформе рассчитывается как соотношение обязательных для наблюдения на КЕ и непосредственно привязанных к ней метрик. Обязательные для сбора метрики определяются на типе КЕ в качестве «слотов», а к этим «слотам» привязываются метрики, собранные в Monq из различных источников. Ну, а для влияния этих метрик непосредственно на здоровье КЕ по ним создаются сигналы.
Метрики и покрытие мониторингом в Monq
Root Cause и Impact Analysis здоровья КЕ
Одним из ключевых функционалов платформы является модель здоровья конфигурационных единиц. Параметры расчета для модели определяются на типах КЕ, а при необходимости могут быть переопределены и на самих КЕ.
Настройка модели здоровья КЕ
Модель позволяет учитывать при расчете здоровья КЕ как связанные с ней сигналы, так и влияющие конфигурационные единицы. Это важно при организации мониторинга сложных ИТ-сервисов, состояние которых невозможно определить стандартными методами мониторинга, но возможно рассчитать на основе состояния компонентов, из которых состоит данный сервис.
Данная модель позволяет проводить анализ корневых причин деградации здоровья КЕ (Root Cause Analysis) по всему графу влияния, а также рассчитывать влияние КЕ и сигналов на вышестоящую КЕ (Impact Analysis).
Анализ корневых причин деградации здоровья КЕ в Monq
Ретроспективный анализ здоровья КЕ
Для проведения ретроспективного анализа здоровья конфигурационных единиц в Monq предусмотрена «Тепловая карта Здоровья» или, если говорить простым языком, визуализация изменения статусов КЕ за выбранный промежуток времени. Данное представление позволяет:
понять, в каком наихудшем статусе находилась каждая КЕ в определенный период времени;
оценить изменения Здоровья КЕ за выбранный промежуток времени;
увидеть наличие либо отсутствие режимов обслуживания в это время у КЕ;
перейти к списку сигналов, повлиявших на КЕ, для выявления причины.
Статусы конфигурационных единиц во времени
Отчеты
Платформа позволяет настраивать различные шаблоны и формировать по ним отчеты как в ручном, так и в автоматическом режиме.
Отчеты о доступности в Monq
Например, так выглядит отчет о доступности ИТ-сервиса, состоящей из 33 конфигурационных единиц. В отчете есть также данные о состоянии каждого элемента этого сервиса (КЕ).
Пример одного из отчетов о доступности
Подробнее о принципах расчета доступности ИТ-сервисов можно узнать из этой статьи.
Синтетическое тестирование в Monq
Кроме метрик, сигналов и логов, платформа позволяет запускать, собирать и обрабатывать результаты автоматизированного (синтетического) тестирования. Оно позволяет имитировать действия реальных пользователей в различных интерфейсах и выявлять возможные проблемы и узкие места в инфраструктуре и приложениях до того, как они начнут массово влиять на конечных пользователей. Сами тесты могут выполняться на стороне заказчика разнообразными средами тестирования, такими как Selenium/Selenide, Vanessa и другие. Среда тестирования выбирается от целей и задач заказчика и никак не зависит от Monq.
Проекты синтетического тестирования
Monq в свою очередь принимает в себя отчеты о выполнении тестов в формате Allure (для этого инструмента есть готовый парсер, но внутри платформы можно написать любой другой), визуализирует их в системе и формирует по ним сигналы. Подробнее узнать о синтетическом мониторинге в Monq можно здесь, а кейс одного из клиентов — тут.
Пример визуализации отчета о синтетическом тестировании
Как в Monq реализован мониторинг инфраструктуры?
В Monq можно отправлять данные мониторинга инфраструктуры, при этом платформа пока не собирает данные с конечных устройств самостоятельно. На текущий момент мониторинг инфраструктуры реализован с помощью агента и плагинов, которые собирают данные из первичных систем. Таким образом, с помощью Monq можно мониторить:
сервера;
сетевые службы и сервисы;
системы резервного копирования и хранения данных;
телефония;
программное обеспечение;
электронная почта;
сетевые устройства;
рабочие станции.
Собственный безагентский мониторинг инфраструктуры — один из наших дальнейших шагов по развитию платформы (таким образом, инфраструктурный мониторинг Monq сможет заменить Zabbix уже в этом году).
Сбор данных в Monq
Сбор данных в Monq организован с помощью потоков.
Потоки данных в Monq
Данные в потоках собираются двумя способами:
Push-модель. Для отправки данных в поток используется API-ключ, который есть у каждого потока. На стороне подключаемой системы происходит подготовка данных, после чего они отправляются на точку API Monq.
Pull-модель. Для сбора данных используются агенты Monq (собственная разработка), на которых установлены специальные плагины — экстракторы данных, позволяющие забрать информацию из внешних систем, оборудования, программного обеспечения любым доступным способом.
Плагины пишутся на C#, а для определения параметров их запуска используются задания в потоках — Yaml-сценарии. Задания могут запускаться вручную, по расписанию, или исполняться непрерывно.
Схема сбора данных в Monq
Дальше эти данные обрабатываются с помощью автоматизации.
Автоматизация в Monq
Автоматизация в платформе позволяет:
автоматизировать сбор данных;
автоматизировать обработку собранных данных;
автоматически строить РСМ и карты здоровья;
запускать скрипты автохилинга;
настраивать корреляцию и дедупликацию;
работать с нотификациями;
запускать эскалацию;
настраивать регламентные действия;
автоматически закрывать сигналы.
Рассказываем, как именно в Monq устроен процесс работы с этими данными и как обеспечить их правильную обработку, а также сделать правильную корреляцию и добиться того, чтобы из большого количества данных, поступающих из различных источников, создались правильные сигналы, которые, в свою очередь, влияли бы на нужный объект мониторинга.
Пример low-code сценария
Выше приведен пример простого сценария, которые отвечает за небольшую задачу. Например, пришел сырой лог из Prometheus и из него нужно сформировать «удобоваримое» для нас как пользователей JSON-событие с определенным набором полей для того, чтобы с этими полями можно было работать внутри системы и видеть их на экране работы с первичными событиям.
В данном случае событие пришло в формате строки, и функция парсера преобразовала его в нужный формат. На этом этапе на него можно навесить какие-то лейблы и таким образом дополнительно обогатить это событие внутри системы определенными метками для того, чтобы дальше при помощи них можно было гибко выстраивать пайплайн внутри дальнейших частей системы.
После того, как произошли некий пре-процессинг и обогащение, событие отправляется дальше внутрь системы по определенному ключу — для этого внутри Monq используется Rabbit. Мы знаем, какой ключ нужно указать для того, чтобы дальше это событие пошло на дальнейшие сценарии.
Корреляция и дедупликация: защита от «шторма алертов»
Сценарием может выступать и чуть более сложная конструкция, которая решала бы более сложные задачи, например, создания сигналов, когда несколько систем мониторинга отправляют данные в зонтик — эти данные могут быть одинаковые в случае наступления какого-то инцидента. Это, как правило, тот самый «шторм» событий, когда данные поступают одновременно из разных источников, и задача этого сценария — понять, что все эти алерты — как события из событийных средств мониторинга, так и метрики, которые создаются при превышении порогового значения, — имеют под собой единую проблему. Благодаря этим сценариям появляется возможность выстроить скрипт таким образом, чтобы в результате в системе не создавалось сотен или тысяч алертов, а создался один инцидент, и все остальные приходящие события и связанные с ним, уже присоединялись непосредственно к нему. Инженер мониторинга сможет увидеть, что создана единая проблема, и у него сразу будет доступ к некой мета-информации, которая будет представлена в журнале в оперативном центре.
Low-code сценарий для дедупликации сообщений
Задача этого сценария еще в том чтобы, если есть услуга или бизнес-сервис, который находится на ресурсно-сервисной модели, например, под Kubernetes. Это событие, которое пришло из внешней системы, отразилось деградацией для того объекта мониторинга, который находится на графе ресурсно сервисной модели и чтобы по нему был создан автоматический сигнал, наносящий урон именно тому объекту, которому он предназначался.
За всё это в Monq отвечают как раз сценарии автоматизации, которые позволяют по уникальным меткам и ключам найти объекты, уже существующие в системе, и присоединить нужные объекты друг к другу.
На базе таких сценариев можно строить и сами ресурсно-сервисные модели. Например, не всегда граф состоит из 100 объектов. Зачастую необходимо начать мониторить внешнюю CMDB, в которой сотни тысяч объектов. Ручное создание этих объектов с последующей поддержкой консистентности этих данных просто по умолчанию невозможно. Monq работает с такими объектами следующим образом: система забирает при помощи специально написанных заданий топологию в формате JSON и дальше на базе сценариев просто парсит их и забирает вне зависимости от степени вложенности (это может быть топология, кластеры, хосты VMware до конечных хостов и устройств, вплоть до порта условного коммутатора). Можно автоматически строить между ними связи, когда есть верхнеуровневая сущность и сущности более низкого порядка, и автоматически настраивая связи влияния по модели здоровья.
Low-code сценарий для автопостроения РСМ
Контент-паки на примере Kubernetes
Такие сценарии можно сделать и вручную, если хочется сделать какую-то интеграцию с нуля, но мы представляем для типовых решений из коробки уже готовый набор этих сценариев — для Zabbix, Prometheus, Kubernetes. Каталог контент-паков будет обогащаться, а среди ближайших — паки для VMware, Linux, Windows.
Пример контент-пака для Kubernetes
Рассмотрим работу контент-паков на примере Kubernetes. К примеру, служба мониторинга отвечает за работоспособность определенного кластера и её задача — сделать так, чтобы за короткий промежуток времени в системе появились объекты, которые относятся к этому кластеру, они начали мониториться и чтобы в результате инженеры мониторинга понимали, когда случилась проблема, и начали оперативно на неё реагировать.
Как это можно реализовать? На одну из нод кластера устанавливается агент Monq, который просто «сходит» в k8s, заберёт из него информацию по объектам кластера, сформирует JSON и отправит в Monq уже с помощью сценариев, которые, кстати, раскатываются при установке контент-пака автоматически. При запуске сценария в системе будут установлены объекты:
— координатор, который будет работать с агентом;
— сценарии построения РСМ.
Таким образом, топология построится автоматически, и в системе начнут рассчитываться сигналы и метрики, которые поступают с объектов Kubernetes. В целом служба получает инструмент, который позволит за несколько минут перетащить топологию в Monq и начать её не только ее мониторить, но и динамически менять её состояние. Понятно, что Kubernetes — это динамическая среда, где количество объектов или сам тип объектов может меняться. Например, произошел автоскейлинг под, и вместо одного их стало уже уже десять или даже сорок. В Monq это отразится таким образом, что объект был один, а стало нужное количество. Связи будут установлены автоматически, мониторинг этих объектов также будет осуществляться автоматически.
В сценариях, которые предоставляются через контент-паки уже есть все необходимые настройки и связи. При этом каждый сценарий можно «подтюнить», — можно добавить различные блоки, парсеры, установиьт связи и пайплайны. Движок low-code автоматизации хорош тем, что для этого не нужно иметь сложных знаний языков программирования и держать штат разработчиков, которые будут строить писать скрипты под каждый сценарий. В случае с Monq любой средний инженер мониторинга за неделю может научиться писать сложные сценарии и дальше их поддерживать.
No-code управление бизнес-процессами эксплуатации
Что делать, когда все покраснело? Как инженеры мониторинга могут управлять алертингом, эскалацией и другими процессами? Для этого Monq существует сервис бизнес-процессов — это уже не low-code технологии, а полноценный no-code движок, который позволяет строить пайплайн и конструкции в зависимости от того, какие действия необходимо выполнить в рамках этого бизнес-процесса.
Пример no-code сценария
Рассмотрим пример такого бизнес-процесса — случился какой-то сигнал. Для него настраивается некий фильтр с условиями: например, если сигнал содержит такое-то название, влияет или связан с определенными конфигурационные единицами и имеет определенную критичность, то нужно запустить этот бизнес-процесс и выполнить следующие действия, например:
отправить оповещения на почту с определенными переменными (их можно забирать из первичных данных или вписать текст самостоятельно);
параллельно с этим оповестить группу инженеров в Telegram или другой мессенджер;
выполнить любой SSH-запрос, если предполагается, что эту ситуацию можно исправить таким образом;
завести инцидент в Jira или любой другой внешний сервис таск-трекинга.
Настройка фильтра сигнала на no-code сценарии
На базе этого можно выстроить матрицу эскалации — перечня действий в случае, если в течение заданного времени инцидент не решен. В этом случае настраивается отложенная проверка на наличие проблемы, эскалируется дальше на вышестоящее руководство или на другую службу. Параллельно можно сигналить ответственных инженерам, чтобы они взяли проблему в работу. Такие сценарии собирается из кубиков действий, которые есть в системе. Эти действия можно как создать самостоятельно, так и скачать из контент-паков.
Даже если вы используете какую-то внешнюю интеграцию, которая не поставляется из коробки в Monq (это могут быть непопулярные или самописные решения), то сделать любую интеграцию можно также средствами low-code движка. На скрине ниже представлена «начинка» блока Telegram, который представляет из себя ту же самую low-code конструкцию, задачей которого является просто формирование правильного запроса к API Telegram.
Возможность редактирования no-code сценария на low-code
Всё действия — уже для того, чтобы из нужных данных сформировать нужный запрос. В этом кроется в принципе любая интеграция Monq с той системой, которая может по http и не только принимать запросы.
Ролевая модель
В Monq реализована ролевая модель, которая позволяет управлять доступами к разной информации внутри организации.
Пользователи имеют возможность выбрать рабочую группу, в контексте которой они хотят работать, — на экране будут отображаться только нужные данные (только объекты, владельцем которых является эта рабочая группа или объекты, которыми поделились с пользователем из других рабочих групп). Таким образом, инженеру, состоящему в нескольких группах, проще сосредоточиться на важном, а все участники одной рабочей группы работают синхронно и видят один экран.
У системы также есть группа администраторов, которые входят во все рабочие группы, имеют доступ ко всем объектам платформы и видят изменения всего ландшафта на своем экране.
Ролевая модель в Monq
Вместо завершения
Если вы дочитали до конца, то, кажется, тема мониторинга вам интересна. Обязательно:
скачайте комьюнити-версию Monq (важная ремарка — установщик для версии Monq 8.0 с no-code автоматизацией будет готов в ближайшие несколько недель, пока для инсталляции доступна предыдущая версия платформы);
приходите на бесплатные вебинары — ближайший состоится уже в эту среду, 27 марта (регистрация — по ссылке);
запишитесь на демо платформы, чтобы узнать, какие задачи Monq может решить в контуре вашей компании, а также обсудить возможности пилотного проекта.
