Привет, Хабр!
В этой статье рассказываем, как устроена low и no-code автоматизация в Monq и как с ее помощью можно оптимизировать обработку данных высоконагруженных систем. В центре внимания – «работяги» – обработчики автоматизации. На конкретных примерах показываем, какие опции использовать, чтобы нагрузка между ними распределялась равномерно. (Кстати, если вам ближе формат видео, то на эту тему у нас есть ролик на Youtube).
На момент написания статьи Monq предназначен для использования в крупных корпорациях с «зоопарком» решений и разрозненным ИТ-окружении, но мы работаем на выпуском облачной версии продукта, которая выйдет уже осенью этого года, – она будет полезна также малому и среднему бизнесу, который зависит от стабильной работы ИТ.
В текущем состоянии Monq объединяет в себе мониторинг инфраструктуры, приложений, пользовательских интерфейсов и зонтичный мониторинг и обеспечивает:
один инструмент наблюдения для хотлайна;
быстрое и эффективное устранение сбоев;
предотвращение аварий;
защиту от «шторма алертов»;
полную картину здоровья ИТ-окружения.
Типы автоматизации в Monq
В Monq в зависимости от задач можно работать со сценариями на:
low-code – такие сценарии позволяют максимально гибко выстраивать процессы сбора, обработки и анализа большого количества данных – логов, метрик, алертов из систем мониторинга, а также выстраивать собственную политику автодискаверинга и создавать модели здоровья.
no-code - более простой инструмент, предназначенный для автоматизации бизнес-процессов, связанных с оповещениями, эскалацией, выполнения регламентных работа и тд.
В таблице приведены основные примеры задач, выполняемых с помощью разных типов сценариев:
low-code |
no-code |
|
Автообработка первичных событий Автопостроение ресурсно-сервисной модели и модели здоровья Автокорреляция и дедупликация для защиты от «шторма алертов» Автоматизация работы с метриками КЕ Парсинг сборок автотестирования Автоматизация формирования бизнес-метрик |
Автоматизация системы оповещений Построение матриц эскалации Нативная интеграция и управление внешними системами Автосоздание и отправка отчетов о доступности и здоровье Автоматизация регламентных действий |
Как устроен движок автоматизации в Monq?
События в платформе распределяются по нескольким маршрутным узлам – логику этого распределения важно понимать, чтобы правильно масштабировать систему в случае возникновения «бутылочного горлышка» на одном из участков системы и сделать так, чтобы эти накопившиеся очереди начали разбираться максимально эффективно.
Тракт обработки данных в Monq
Вот как выглядит основной тракт обработки данных в Monq:
Давайте пройдемся по тракту пошагово и посмотрим, на каких этапах этого процесса задействована автоматизация. На этапе сбора данных логи, метрики, события из систем мониторинга поступают напрямую в Monq из разрозненных источников (Zabbix, Prometheus, vCenter и др.) и из внешних сред автотестирования, а также собираются самостоятельно агентом платформы по заданиям.
Из внешних источников Monq получает данные в виде:
событий, которые поступают через потоки данных. Например, в Monq пришло событие о проблеме из Zabbix. В этом случае платформе необходимо внутри себя найти конфигурационную единицу, которая является основным объектом мониторинга, и сделать так, чтобы то событие, которое пришло из Zabbix автоматически, создало или подтвердило события алертинга внутри Monq – то есть сигнал создался и привязался к нужной конфигурационное единице.
метрик – в Monq есть правила обработки метрик, которые по заданному расписанию определяют, какому пороговому значению соответствует значение метрики, создает или закрывает пороги и передает их для дальнейшего расчета по тракту.
В этом процессе именно сценарии автоматизации отвечают за то, чтобы если одна из метрик превысила пороговое значение или пришло проблемное сообщение из системы мониторинга, это отразилось бы на здоровье и статусе нужной конфигурационной единицы. Это сценарии корреляции порогов, корреляции сигналов, автопостроения РСМ и обработки отчета тестирования – на схеме выше они выделены фиолетовым цветом и помечены специальной иконкой. Они находятся в разных местах. Почему? Для работы таких сценариев требуются различные данные. Так, для сценария обработки отчета тестирования на вход должна прийти сырая сборка в виде zip-архива – Monq автоматически получает информацию о ее поступлении и запускает специальный сценарий – парсер, который преобразует архив в виде приемлемого события. Дальше это событие обрабатывается системой по тракту и поступает на расчет сигналов. Аналогичным образом в Monq приходят первичные события из внешних систем мониторинга или других систем. Они отправляют в Monq данные, или система забирает их сама, и определяет, что это за событие:
если это событие – проблема, по нему можно создавать, закрывать или подтверждать сигнал;
если это пороги – они открываются и закрываются на сценарии предобработки и дальше отправляются на расчеты здоровья и статусы КЕ;
если речь про событие мониторинга, то оно дальше идёт на расчёт сигналов, и уже сигнал вбирает в себя наибольшее количество событий и на своей стороне и запускает при необходимости уже no-code сценарий с действиями, например, нотификации и эскалации, автохилинга, заведения тикета в сервис-деск.
Маршрутные узлы и обработчики автоматизации
Данные участка, подкрашенного на схеме с трактом обработки данных в фиолетовый цвет, являются маршрутными узлами.
На схеме отображена наша маршрутная карта автоматизации, в которой:
голубым цветом отмечены маршрутные узлы – их всего шесть;
оранжевым цветом отмечены сервисы, которые делятся событиями.
Также между элементами карты протянуты связи, которые определяют маршруты, по которым идут те или иные события, например, события потоков. Например, мы получили событие, оно попало на маршрутный узел парсинга логов и после него отправляется на целых три маршрутных узла, так как по потокам могут приходить события о создании алерта, о миграции виртуальной машины, об изменении параметров конфигурационных единиц, и Monq должен отправить это событие на расчёт сигналов и автопостроение РСМ и моделей здоровья. По этому же событию могут запускаться, создаваться и закрываться сигналы и настраиваться no-code бизнес-процессы таким образом, чтобы, например, отправлялись оповещения ответственным или создавались тикеты по приему событий из потоков.
По умолчанию в Monq все шесть маршрутных узлов работают с одним обработчиком, или раннером, который запускает сценарии автоматизации (именно такое ограничение стоит на комьюнити-версии платформы). Обработчик по умолчанию распределяется по всем маршрутным узлам, чтобы гарантировать обработку всех событий. Один раннер прекрасно справляется с небольшим количеством данных – например, десятком сообщений в секунду. Однако при увеличении объема поступающей информации – например, до ста сообщений в секунду, нагрузка на обработчик увеличивается и есть риск возникновения бутылочного горлышка. Очевидный инструмент решения задачи – увеличить количество обработчиков, однако делать это можно разным способом с использованием различных функциональных особенностей Monq.
Опции работы с обработчиками автоматизации
Рассмотрим пример, когда по параметрам лицензии пользователю доступно пять обработчиков. Существует несколько опций работы с ними.
Опция #1: увеличение числа обработчиков (обычный скейлинг). Если пользователь просто поднимает количество обработчиков до двух, то сервис распределит всю нагрузку поровну. Каждый обработчик получит по три узла для обработки. Однако в этом случае распределение будет равномерным только по количеству узлов, без учета реальной нагрузки на них. Таким образом, в случае явного возникновения узкого места простое увеличение кол-ва обработчиков работает неэффективно.
Опция #2: назначение эксклюзивности. Именно поэтому в Monq существует опция эксклюзивности – назначив ее на определенный маршрутный узел, он гарантированно всегда будет обрабатываться отдельным обработчиком. Вроде проблема решена, но что делать, если объем данных увеличивается еще больше, и обработчик снова копит очереди? Можно было бы просто увеличить количество обработчиков еще раз, однако координатор и их распределить поровну – обработка сигналов от этого не ускоряется, потому что эксклюзивный обработчик есть, но он один.
Опция #3: рекомендуемое количество обработчиков. Для такой ситуации в платформе существует дополнительная опция – рекомендуемое количество обработчиков (по умолчанию оно везде равняется единице). Тогда при увеличении числа обработчиков система будет действовать следующей логике: первый раннер – равномерно на все маршрутные узлы, кроме эксклюзивного; второй и последующие – на эксклюзивный маршрутный узел. В этом случае увеличение числа обработчиков будет эффективным и позволит обрабатывать столь угодно большие объемы данных.
На примере в этом видео наглядно показываем, как изменения различных параметров позволяют эффективно бороться с накоплением очередей. В дальнейших статьях и видео расскажем, как действовать при обработке сотен событий в секунду в системе с миллионами конфигурационных единиц.
Обязательно продолжим обзор автоматизации в Monq – в следующих материалах разберем расчет сигналов на примере событий Zabbix с применением средств дедупликации и различных других инструментов, которые мы рекомендуем использовать при работе с высоконагруженные системами. Кроме того, рассмотрим кейс со “штормом алертов” и инструменты, с помощью которого его можно подавить.
Кстати, если вы хотите попробовать Monq, то ссылке доступна бесплатная комьюнити-версия. Если хотите обсудить пилот и внедрение в вашей компании – приходите на индивидуальное демо.