В последние годы среди организаций, живущих философией DevOps и SRE, стал популярен подход “всего как кода”. Особенно часто он встречается при управлении инфраструктурой. Направление IaC (infrastructure as a code), где ручная настройка заменяется использованием скриптов, появившись в ответ на растущую виртуализацию данных, превратилось в IT-стандарт и неотъемлемую часть DevOps. Представление инфраструктуры в виде кода обеспечивает её гибкость и масштабируемость, автоматизирует ручные задачи, минимизирует риск человеческого фактора и позволяет эффективнее использовать существующие ресурсы. Но рука об руку с инфраструктурой идёт и её мониторинг, а потому резонным является вопрос о том, как на нём отразилась описанная выше концепция.
В этой статье я расскажу про такой подход как Monitoring as a Code и покажу его реализацию на примере нашей платформы для мониторинга и автоматизации Monq 7.0.
Мониторинг как код – это НЕ инфраструктура как код
Если мы прогуглим “мониторинг как код”, то найдем упоминания этого подхода у множества популярных инструментов мониторинга. Однако стоит копнуть глубже, и станет понятно, что описываемые методы – это вовсе не “мониторинг как код”, а всего лишь развертывание агента и настройка экспорта с помощью инструментов управления конфигурацией, таких как Puppet, Terraform или Helm. Во многом это результат попытки адаптировать традиционные инструменты мониторинга и рабочие процессы к современной парадигме DevOps. Грубо говоря, мы встречаем всю ту же “инфраструктуру как код” для осуществления мониторинга. По большей части такие инструменты покрывают не весь мониторинг, а ограничиваются простой конфигурацией сбора данных.
Включение автоматизации мониторинга в инициативу “инфраструктура как код” — это всё же не комплексное решение для мониторинга. “Мониторинг как код” — это не просто автоматическая установка и настройка агентов, подключаемых модулей и экспортеров. Он охватывает весь жизненный цикл, включая автоматическую диагностику, оповещения, управление инцидентами и даже автоматическое устранение сбоев.
В одной из предыдущих статей я рассказывал про автоматизацию, дискаверинг и прочие новые функции платформы Монк, которые успешно автоматизируют большинство процессов поддержки и мониторинга через сценарии, написанные на low-code движке – от построения ресурсно-сервисной модели (РСМ) до настройки автодействий и автоправил. Не буду снова описывать все фишки, так как все они довольно подробно рассмотрены в указанной статье. Однако недавно мы выпустили новую версию платформы, которая ещё больше позволяет нам относить их к настоящим представителям концепции “мониторинга как кода”. Про эти изменения я и хотел бы рассказать.
От статических триггеров к динамическим сценариям
В предыдущих версиях Monq основным инструментом дедупликации и корреляции первичных событий (алертов и логов) были синтетические триггеры, управляемые правилами в виде lua-скриптов. Несмотря на их гибкость, сами триггеры имели статическую природу, что доставляло определенные неудобства при управлении большими динамическими окружениями. Для каждого события приходилось создавать отдельный триггер со своим правилом. При большом объёме постоянно меняющихся данных количество триггеров могло доходить до десятков, а то и сотен тысяч! Всё это порождало дополнительные трудозатраты при настройке и дальнейшей работе с системой.
Как я уже упоминал, Monq легко синхронизуется с другими популярными системами мониторинга данных. Но наличие статических триггеров порождало проблему этой постоянной синхронизации - приходилось постоянно отслеживать изменения синхронизируемых систем. В случае удаления триггера или отвязки его от конфигурационной единицы происходила потеря истории. Все это делало затруднительным полноценное использование Monq для мониторинга динамически изменяющихся сред.
Здесь на помощь пришёл всё тот же low-code движок, который в новой версии Monq позволил заменить синтетические триггеры на сигналы, управляемые сценариями автоматизации. По своей природе сигнал похож на задачу в обычном таск-трекере, и в отличие от триггера, где менялся только статус, сигнал является динамическим “короткоживущим” объектом. Он открывается по определенному событию (или набору событий), может присоединять в процессе другие подтверждающие алерты и так же по алерту или событию из планировщика закрывается.
Подробнее концепция автоматизации в оновленном 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 не только сокращает время пользователя на рутинные ручные задачи, но и защищает от информационного шума.
V. После создания сигнала событие попадает на расчет статуса конфигурационной единицы. Привязанная к сигналу КЕ перенимает его критичность. Например, если к какой-то КЕ привязан критичности уровня fatal, то и КЕ окрашиваются в соответствующий ему ярко-красный цвет. Смена статус КЕ, в свою очередь, производит перерасчет её здоровья и запускает соответствующие действия (например, оповещения команды, рассылки пользователям или скрипты автопочинки). И всё это, повторюсь, автоматически!
Сценарий рулит
Конечно, сценарии имели место и в случае триггеров. Перед привязкой (вручную или через API) триггера к нужной конфигурационной единице необходимо было задать скрипт управления его статусами (вручную или через шаблон), а также префильтр событий. Получалось, что за каждый отдельный триггер отвечал отдельный скрипт.
В случае сигналов в новой версии Monq целиком изменился подход к их управлению - теперь оно целиком отдано сценариям. По аналогии с упомянутым выше автопостроением ресурсно-сервисной модели все связанные с сигналами процессы реализуются внутри написанного c помощью low-code сценария. Именно внутри сценария происходит открытие/закрытие сигналов, определяется логика их привязки к конфигурационным единицам, а также присоединение к ним событий (алертов). Кроме того, сигналы могут управляться целым набором сценариев: можно создать один огромный сценарий дедупликации алертов, а можно разбить на множество маленьких без каких-либо ограничений.
Там же в сценарии конфигурационная единица (КЕ) привязывается к сигналу: непосредственно из скрипта можно обратиться к функциям CMDB, найти по атрибутам нужную КЕ и привязать её к ней сигналу. Логика привязки может абсолютно произвольной и зависит только от устройства CMDB и настройки источника логов.
В целом у продукта Monq довольно подробная документация, где в том числе описана работа с сигналами и приведены примеры сценариев автоматизации.
Я же со своей стороны попытаюсь описать концепцию сигналов на простом примере дедупликации алертов. Представьте, что в случае превышения порогового значения метрики источник каждые 5 минут генерирует алерт о превышении. В Monq по первому событию открывается сигнал, все последующие подтверждения присоединяются к этому сигналу. При возвращении метрики в исходное состояние и отсутствия новых алертов по данной метрике в течение 30 минут Monq сигнал закрывает. В случае повторения ситуации генерируется новый сигнал, а ранее сработавшие и уже закрытые сигналы остаются неизменными.
Подобный динамический сценарный подход при управлении проблемами значительно упрощает процесс постановки на мониторинг, что особенно актуально для систем с динамическим окружением (контейнеры, микросервисная архитектура, Kubernetes). Проще говоря, вместо того чтобы настраивать десятки и сотни тысяч статических триггеров и постоянно следить за их актуальностью, в новой версии Monq достаточно написать несколько сценариев и забыть о старом процессе постановки на мониторинг – всё остальное сделает система, что вполне в духе концепции “мониторинг как код”.
От нескольких экранов к единому окну
Не только автоматизация, но и представление данных влияет на эффективность мониторинга. Поэтому помимо сценарного управления в новой версии Monq обновился и сам подход к визуализации данных. Раньше пользователю Monq приходилось, хоть и в рамках одной системы, но всё же постоянно переключаться между несколькими экранами: главным, оперативным, шкалой времени и ресурсно-сервисной моделью в виде топологии. Пусть это не доставляло существенных неудобств, но увеличивало время на устранение сбоя.
Поэтому теперь все функции четырёх экранов собраны в едином окне мониторинга, где мониторинговая панель совмещена с графом РСМ.
Единое окно разделено визуально на две части: в левой панели находится список отфильтрованных КЕ, их здоровье и статус, на правой панели информация меняется в зависимости от выбранного режима оператором: граф РСМ, карточка КЕ, список сигналов, сервисные режимы, лог изменений. На экране действует множество разнообразных кросс-ссылок и фильтров.
Еще одной фишкой стал функционал точек перехода между картами. Можно привязать карты к определенным конфигурационным единицам, после чего на этих конфигурационных единицах появятся точки перехода. Таким образом, можно из одной карты переходить в другую непосредственно на графе РСМ.
Такая концепция “одного окна” призвана ускорить работу с находящимися на мониторинге объектами, и, таким образом, минимизировать время решения проблемы.
Итог
В широком смысле “мониторинг как код” использует тот же подход, что и “инфраструктура как код”, с которым он тесно связан: вы управляете мониторингом так же, как вы управляете приложениями, серверами или другими компонентами инфраструктуры. Здесь так же используется высокоуровневый синтаксис для описания инструментов мониторинга, фреймворков, предмета мониторинга и времени отправки оповещений. Это означает, что настройки мониторинга, процессы и правила могут быть версионными, общими и повторно использоваться. Поэтому далеко не все платформы, использующие средства автоматизации для сбора данных, могут похвастаться применением концепции “мониторинга как кода” в полной мере. Monq – один из тех продуктов, где данный подход применяется с начала разработки и новая версия платформы стала мощным витком в его реализации.
Скачать бесплатную версию можно тут.
А в этом канале мы делимся с вами новостями, планами развития, интересными фактами и кейсами из отдела разработки компании Монк.