В этой статье я расскажу про такой подход как Monitoring as a Code и покажу его реализацию на примере нашей платформы для мониторинга и автоматизации Monq 7.0.
Мониторинг как код – это НЕ инфраструктура как код
Если мы прогуглим “мониторинг как код”, то найдем упоминания этого подхода у множества популярных инструментов мониторинга. Однако стоит копнуть глубже, и станет понятно, что описываемые методы – это вовсе не “мониторинг как код”, а всего лишь развертывание агента и настройка экспорта с помощью инструментов управления конфигурацией, таких как Puppet, Terraform или Helm. Во многом это результат попытки адаптировать традиционные инструменты мониторинга и рабочие процессы к современной парадигме DevOps. Грубо говоря, мы встречаем всю ту же “инфраструктуру как код” для осуществления мониторинга. По большей части такие инструменты покрывают не весь мониторинг, а ограничиваются простой конфигурацией сбора данных.Включение автоматизации мониторинга в инициативу “инфраструктура как код” — это всё же не комплексное решение для мониторинга. “Мониторинг как код” — это не просто автоматическая установка и настройка агентов, подключаемых модулей и экспортеров. Он охватывает весь жизненный цикл, включая автоматическую диагностику, оповещения, управление инцидентами и даже автоматическое устранение сбоев.
В одной из предыдущих статей я рассказывал про автоматизацию, дискаверинг и прочие новые функции платформы Монк, которые успешно автоматизируют большинство процессов поддержки и мониторинга через сценарии, написанные на low-code движке – от построения ресурсно-сервисной модели (РСМ) до настройки автодействий и автоправил. Не буду снова описывать все фишки, так как все они довольно подробно рассмотрены в указанной статье. Однако недавно мы выпустили новую версию платформы, которая ещё больше позволяет нам относить их к настоящим представителям концепции “мониторинга как кода”. Про эти изменения я и хотел бы рассказать.
От статических триггеров к динамическим сценариям
В предыдущих версиях Monq основным инструментом дедупликации и корреляции первичных событий (алертов и логов) были синтетические триггеры, управляемые правилами в виде lua-скриптов. Несмотря на их гибкость, сами триггеры имели статическую природу, что доставляло определенные неудобства при управлении большими динамическими окружениями. Для каждого события приходилось создавать отдельный триггер со своим правилом. При большом объёме постоянно меняющихся данных количество триггеров могло доходить до десятков, а то и сотен тысяч! Всё это порождало дополнительные трудозатраты при настройке и дальнейшей работе с системой.Как я уже упоминал, Monq легко синхронизуется с другими популярными системами мониторинга данных. Но наличие статических триггеров порождало проблему этой постоянной синхронизации - приходилось постоянно отслеживать изменения синхронизируемых систем. В случае удаления триггера или отвязки его от конфигурационной единицы происходила потеря истории. Все это делало затруднительным полноценное использование Monq для мониторинга динамически изменяющихся сред.
Здесь на помощь пришёл всё тот же low-code движок, который в новой версии Monq позволил заменить синтетические триггеры на сигналы, управляемые сценариями автоматизации. По своей природе сигнал похож на задачу в обычном таск-трекере, и в отличие от триггера, где менялся только статус, сигнал является динамическим “короткоживущим” объектом. Он открывается по определенному событию (или набору событий), может присоединять в процессе другие подтверждающие алерты и так же по алерту или событию из планировщика закрывается.
Подробнее концепция автоматизации в оновленном Monq представлена в виде следующей схемы:
I. Первичное событие в виде сырых данных попадает в систему через Потоки данных (метод push) или с помощью так называемых Агентов (метод pull).
Push-метод подразумевает отправку данных через REST HTTP API (API потоков данных). Таким образом интегрируются Prometheus, Ntopng, Fluentd и Nagios Core.
Pull-метод осуществляет подключение и сбор данных из мониторинговых инструментов с помощью Агентов Monq. Агент — это специальная программа, которую можно установить на удаленное устройство с целью сбора данных и выполнения каких-либо действий. Monq Agent получает с Monq сервера задания, выполняет их и собранную информацию передает по защищенному сетевому протоколу на сервер. В Monq можно использовать как готовые шаблоны конфигурации и плагины, так и написать собственные задания и обработчики. Через метод pull реализуются интеграции с Zabbix, SCOM, Nagios XI, vCenter.
II. После попадания в систему с помощью ETL-логов событие приводится к соответствующей структуре Monq. В таком виде мы видим события и алерты в самой системе.
III. Далее сценарий автоматизации определяет, что за событие мы получили: событие мониторинга (поломка какого-то объекта инфраструктуры или недоступность сервиса) или событие изменения топологии (например, создание новой конфигурационной единицы (КЕ) или изменение её названия). На каждый из таких случаев имеется свой сценарий (или группа сценариев).
Во втором случае мы имеем дело с автодискаверингом и автопостроением ресурсно-сервисной модели, у которых я уже рассказывал: при помощи сценариев автоматизации Monq позволяет не только строить топологию всех ИТ-сервисов, но и обновлять её без применения ручного труда. Однако здесь стоит отметить, что после того, как КЕ меняется, событие об этом изменении также попадает на расчёт сигналов.
IV. Теперь переходим к изюминке обновленного Monq – сигналам.
Сигнал - это динамический “звоночек”, свидетельствующий об изменении в инфраструктуре и имеющий время начала и время завершения. Он сообщает о выходе какого-либо параметра из штатного состояния и в основном предназначен для дедупликации и корреляции первичных событий. С помощью сигналов устраняются избыточные копии, а также происходит корреляция событий – инцидентам присваивается соответствующий приоритет.
Таким образом, при помощи автоматических сценариев Monq не только сокращает время пользователя на рутинные ручные задачи, но и защищает от информационного шума.
Сценарий рулит
Конечно, сценарии имели место и в случае триггеров. Перед привязкой (вручную или через API) триггера к нужной конфигурационной единице необходимо было задать скрипт управления его статусами (вручную или через шаблон), а также префильтр событий. Получалось, что за каждый отдельный триггер отвечал отдельный скрипт.В случае сигналов в новой версии Monq целиком изменился подход к их управлению - теперь оно целиком отдано сценариям. По аналогии с упомянутым выше автопостроением ресурсно-сервисной модели все связанные с сигналами процессы реализуются внутри написанного c помощью low-code сценария. Именно внутри сценария происходит открытие/закрытие сигналов, определяется логика их привязки к конфигурационным единицам, а также присоединение к ним событий (алертов). Кроме того, сигналы могут управляться целым набором сценариев: можно создать один огромный сценарий дедупликации алертов, а можно разбить на множество маленьких без каких-либо ограничений.
Я же со своей стороны попытаюсь описать концепцию сигналов на простом примере дедупликации алертов. Представьте, что в случае превышения порогового значения метрики источник каждые 5 минут генерирует алерт о превышении. В Monq по первому событию открывается сигнал, все последующие подтверждения присоединяются к этому сигналу. При возвращении метрики в исходное состояние и отсутствия новых алертов по данной метрике в течение 30 минут Monq сигнал закрывает. В случае повторения ситуации генерируется новый сигнал, а ранее сработавшие и уже закрытые сигналы остаются неизменными.
Подобный динамический сценарный подход при управлении проблемами значительно упрощает процесс постановки на мониторинг, что особенно актуально для систем с динамическим окружением (контейнеры, микросервисная архитектура, Kubernetes). Проще говоря, вместо того чтобы настраивать десятки и сотни тысяч статических триггеров и постоянно следить за их актуальностью, в новой версии Monq достаточно написать несколько сценариев и забыть о старом процессе постановки на мониторинг – всё остальное сделает система, что вполне в духе концепции “мониторинг как код”.
От нескольких экранов к единому окну
Не только автоматизация, но и представление данных влияет на эффективность мониторинга. Поэтому помимо сценарного управления в новой версии Monq обновился и сам подход к визуализации данных. Раньше пользователю Monq приходилось, хоть и в рамках одной системы, но всё же постоянно переключаться между несколькими экранами: главным, оперативным, шкалой времени и ресурсно-сервисной моделью в виде топологии. Пусть это не доставляло существенных неудобств, но увеличивало время на устранение сбоя.Поэтому теперь все функции четырёх экранов собраны в едином окне мониторинга, где мониторинговая панель совмещена с графом РСМ.
Такая концепция “одного окна” призвана ускорить работу с находящимися на мониторинге объектами, и, таким образом, минимизировать время решения проблемы.