Привет, Хабр!
Простая истина: когда какой-то элемент инфраструктуры или бизнес-сервис простаивает, то компания несёт потери. Чем понятнее текущее состояние ИТ, тем быстрее можно реагировать на возникающие проблемы и не допускать простоев. Для этого, конечно, нужен мониторинг.
Рассказываем, какой концептуальный подход к мониторингу мы применяем в команде НЛМК ИТ и как идёт один из наших проектов по внедрению зонтичного мониторинга и автоматизации на базе российской платформы Monq. Читать всем, кто хочет агрегировать данные из различных инструментов мониторинга в одном месте и автоматизировать управление этими данными.
Концепция мониторинга в НЛМК: архитектура и принципы есть, осталось найти инструмент
Если взять одну из классических схем подходов к мониторингу в принципе, мы приближаемся к верхним ступеням развития – мы уже давно прошли этапы простого инфраструктурного мониторинга отдельных элементов и хотим смотреть на работу сервисов в комплексе, учитывая их взаимосвязи, и воздействие на критически важные для нас бизнес-сервисы.
До внедрения MONQ мы использовали Grafana в связке с разными инструментами мониторинга Zabbix, Prometheus и т.д.
В Grafana с помощью плагинов мы выстроили базовую ресурсно-сервисную модель, которая отражала состояние высокоуровневой конфигурационной единицы (КЕ), например, определенную ИТ-услугу, далее – состояние информационной системы, которая, в свою очередь, дробилась на компоненты. Это помогло нам свести все события в едином месте (в первую очередь критически важные, которые приводят к аварийным или предаварийным инцидентам) и оперативно определять к какой ИТ-услуге и ИТ-системе относится то или иное событие конкретной КЕ. Благодаря этому удалось сократить время реагирования, регистрации и устранения инцидентов, поскольку ситуационному центру ИТ стало проще работать в едином месте и с едиными наименованиями, стало проще с определением ответственных за устранение инцидентов.
Однако количество систем, ставящихся на мониторинг и количество мониторов становилось все больше и нам не хватало инструмента, который:
поможет автоматизировать действия ситуационного центра ИТ
сможет шаблонизировать и упростить заведение КЕ на мониторинг.
поможет анализировать аномалии и выставлять пороги автоматически
позволит разным командам работать с мониторингом в едином месте
при этом в перспективе даст возможность использовать ИИ для построения мониторов и формирования карты потока данных
Мы рассматривали вариант разработки собственного инструмента и искали готовые решения на рынке. В итоге пришли к выводу, что оптимальным решением будет купить перспективный инструмент зонтичного мониторинга на рынке.
Немного расскажу про архитектуру мониторинга сейчас. Как видно из таблицы выше, мы сейчас в процессе перехода на мониторинг ИТ-сервисов. В рамках данного перехода мы обсуждаем с бизнесом критически важные операции для них предоставляемые в рамках ИТ-сервисов, те, которые влияют на бизнес драйверы (KPI бизнеса). Совместно с бизнесом утверждаем конкретные индикаторы и целевые пороги по данным операциям для постановки на мониторинг. В будущем мы планируем регистрировать аварийные инциденты в случае нарушения целевых показателей по операциям, которые критичны для бизнеса. Большинство существующих инфраструктурных и прикладных событий переведем в предаварийные (но не все, какие – то самые очевидные, которые в моменте приведут к резкому снижению целевых показателей по операциям, мы оставим аварийными).
Сейчас, до окончательного перехода на мониторинг ИТ-сервисов, по большинству ИТ-сервисов/ИТ-систем мы экспертно определяем, какие события и для каких КЕ приведут к негативному влиянию на информационную систему/ИТ-сервис и на пользователей данных сервисов/систем. Соответственно по таким событиям регистрируем аварийные инциденты. Также регистрирем инциденты и по событиям, которые являются предаварийными, которые еще не повлияли на сервисы/системы и их пользователей, но не ждущих отлагательств и которые в скором времени могу перерасти в аварийные инциденты.
В MONQ мы не выстраиваем сложных моделей, что если упадет ИБП, то он с каким-то процентом повлияет на горизонтальные и вышестоящие КЕ, сначала на железные сервера и железные сетевые устройства, те в свою очередь на виртуальные сервера, дальше на приложения, дальше на информационные системы и они на ИТ-сервисы. У нас модель построена таким образом, что для ИБП сразу определяются события, которые являются аварийными и какие предаварийными. Например, если два ИБП в резерве обеспечивают работоспособность ИТ-сервиса и упадет только один ИБП, то без всяких сложных расчетов с весами, вышестоящая КЕ ИТ-сервиса загорится соответствующим цветом для предаварийного инцидента, будет автоматически зарегистрирован инцидент высокого приоритета в ITSM системе, авт. будет создан чат и в него добавлены только тех. специалисты ответственные за поддержку ИБП, не будет авт. оповещений на менеджеров услуг, пользователей и руководство. И все потому, что резервный ИБП выдержит нагрузку и влияния на пользователей, процессы не будет. Да, могут быть исключения, когда один ИБП не выдержит нагрузки (может резервный стоял слабее основного), но в подавляющем большинстве случаев произойдет именно так, как написано выше. Такой принцип настройки мониторинга мы применяем не только к ИБП, а в целом ко всему, для всех КЕ и по разным метрикам, не только по доступности.
Критерии выбора
Таким образом, с архитектурой построения мониторинга мы давно определились, и приступили к поиску решения. На внедряемое сейчас решение – российский ИТ-мониторинг Monq – больше обратили внимание из-за автоматизации. Нам стало понятно, как автоматизировать процессы и упростить работу нашим инженерам, которые могут на уровне скриптов и какой-то структуры сделать автоматизированные шаблоны, которые будут автоматически заполняться – и таким образом еще и провести стандартизацию. Конечно, можно настраивать такие сценарии на каких-то других инструментах, но гораздо более разумно настроить всю автоматизацию на конечном зонтике, куда собираются все данные.
Изначально нам была нужна система, которая:
являлась бы AIOps-платформой, или имела бы функции искусственного интеллекта и машинного обучения;
могла бы агрегировать большой объем информации, выступая «зонтиком» для других мониторинговых систем, и представлять данные в структурированном виде, но не только с точки зрения каких-то определенных тегов, описания и комментариев. Мы хотели видеть комплексную картину, из чего у нас выстраивается сервис системы и из каких компонентов он состоит. Возможность собрать воедино все данные в одно решение – это один из самых главных для нас плюсов и аспект удобства: мы стремимся всё свести в одну систему и уйти от множества разных инструментов мониторинга. Наша конечная цель – перейти к работе в одном окне.
должна была бы обеспечить автоматизацию рутинных задач ситуационного центра, сократить время реагирования и усилия на определение ответственных, интеграцию с ITSM, проверку событий ЗНИ, отправку оповещений и взаимодействие в чатах.
Наши ключевые цели при выборе решения заключались в следующем:
Предоставить ситуационному центру инструмент, который позволит автоматизировать рутинные операции, формализовать реагирование на инциденты и сократить долю ручного труда. Мы стремились к тому, чтобы вся процедура — от идентификации проблемы до формирования рабочего чата с ответственными специалистами и регистрации инцидентов — происходила без вмешательства инженеров.
Обеспечить интегрированный обзор всей ИТ-инфраструктуры в одном интерфейсе, исключив необходимость переключения между многочисленными системами мониторинга. Это повышает оперативность и снижает вероятность ошибок, связанных с разрозненностью инструментов.
С точки зрения бизнеса, мы ставили задачу минимизировать риски и убытки от простоев за счёт чёткой структуры процессов, прозрачности и автоматизации цепочек реагирования. Такой подход снижает финансовые потери при возникновении аварийных инцидентов и повышает обоснованность управленческих решений.
Ещё одним дополнительным фактором было развитие системы вендором – мы вкладываемся не только в текущее состояние платформы, но и в будущие возможности (например, в этой осенью 2024 года в Monq вышли ML-функции, которых не было год назад, – прогнозирование сбоев в результате анализа временных рядов). Нам, чтобы развивать собственные подобные инструменты, пришло бы держать собственные экспертизу и компетенции в большом количестве.
Этапы внедрения зонтичного мониторинга
Условно этапы внедрения зонтичного мониторинга в НЛМК можно представить на схеме:
Как видно, сейчас мы завершаем первый этап внедрения и тестирования системы в реальной работе ситуационного центра – уже прошли все необходимые шаги для постановки на мониторинг девяти информационных систем и сейчас на этапе настройки ролевой модели.
Про концептуальный подход к мониторингу мы рассказали в предыдущей статье – остановимся немного на некоторых других интересных шагах этой схемы.
Автоматизация – прежде всего
Как отмечалось, Monq заинтересовал нас автоматизацией. Мы хотели сократить время реакции и расследования: чтобы не инженеры вручную анализировали проблему, а система сама определяла её и уведомляла нужных специалистов.
За счет автоматизации намеревались исключить человеческий фактор и, соответственно, сократить время реакции на инцидент. Monq также должен был автоматически создавать КЕ с нужными атрибутами, реагировать на изменения порогов.
Сейчас Monq – конечный пункт, куда автоматически поступают данные от всех систем мониторинга и внешних источников, где они обрабатываются, проходя весь путь от поступления до эскалаций и нотификаций, если случается аварийный или предаварийный инцидент. В платформу стекаются не только метрики и логи, но и данные синтетического мониторинга и автотестирования – Monq, в свою очередь, выступает как то самое единое место, куда отправляются только отчеты о результатах. Результаты синтетического тестирования, естественно, привязываются к КЕ и влияют на ее здоровье, как и любые другие события в системе. А уже после расчета здоровья таких КЕ заводится инцидент того или иного приоритета.
Одним из примеров достигнутой автоматизации является непосредственная работа с устранение аварийных инцидентов. Раньше специалисты ситуационного центра анализировали проблему, вручную создавали инциденты, вручную добавляли необходимых сотрудников в чат в мессенджере и др. Monq делает это все автоматически – регистрирует инциденты с описанием произошедшего, назначает событие на нужную рабочую группу, закрывает их.
Кроме того, Monq помогает отрабатывать сверку событий с запросами на изменение (ЗНИ). У ЗНИ есть плановый даунтайм, и, чтобы не создавать ложных алертов, если система видит плановые работы, просто отправляет оповещение на нужного специалиста для сверки и подтверждения.
Все процессы, связанные с оповещением ответственных и работой с инцидентами, автоматизируются с помощью no-code. Пример одного из таких сценариев приведен ниже.
Интересный момент про развитие продукта, который мы заметили за время использования – ранее в платформе вся автоматизация была на Lua-скриптах – она работала, но были сложности. Например, все действия в Lua скрипте необходимо выполнять последовательно, что ограничивало логику применения. Или нельзя было просто отложить исполнение действия в скрипте на заданное время, для этого нам пришлось придумать дополнительный snmp-запрос, который висел 25 секунд и после этого выполнял сценарий. Сейчас же с no-code можно просто организовывать любые ветвления с помощью блока “Switch” и откладывать исполнение действия благодаря “Wait”.
Ресурсно-сервисная модель и low-code
Данные из наших информационных систем – логи и метрики – сейчас собираются в Monq автоматически (с помощью настроенных интеграций) несколькими способами – напрямую и с помощью и плагинов, которые с определенной периодичностью собирают необходимые для нас данные. Собираем централизовано с Victoria Metrics или экспортерами.
На основании собранных данных в Monq можно выстраивать ресурсно-сервисную модель (РСМ). Пока отрисовка и наполнение РСМ у нас на мануальном приводе – мы сначала тестируем подход прежде, чем полностью автоматизировать процесс. Для того, чтобы получить качественный результат, нужно стандартизировать входящие данные. Как говорится, чтобы что-то красиво отрисовать, сначала что-то красивое надо получить.
Сбор и обновление данных при этом полностью автоматизированы. Мы используем правила порогов по метрикам и сценарии создания сигналов – у нас они полностью кастомны и написаны с нуля именно под наши задачи. У Monq есть и стандартные контент-паки для разных систем и кейсов применения, но поскольку принцип создания инцидентов в нашей конфигурации сильно отличается от заложенного в эти готовые пакеты, мы создали свои собственные, частично использовав стандартные в качестве примеров., При этом мы разделили потоки данных на несколько этапов при отборе событий, потому что нам нужно:
сначала найти КЕ-первоисточник и с нее подтянуть необходимые атрибуты;
на основании этих атрибутов найти вышестоящую КЕ;
провалиться по связям влияния;
найти все услуги, на которые оказывается влияние;
снять необходимые атрибуты с них;
всё собрать для того, чтобы после этого запустилась автоматизация.
Сейчас мы работаем над тем, чтобы все метрики автоматически, без существенных дополнительных настроек, привязывались к нужным КЕ. Пока атрибутивный состав у нас предельно простой – автоматическая привязка КЕ строится вокруг одного ключевого для нас атрибута. C его помощью автоматон Monq сверяет значения с лейблами метрики и привязывает к КЕ порог.
Во время внедрения мы также решали задачи, связанные с обработкой больших объёмов одновременно поступающих данных. Например, при массовом обновлении множества порогов могло возникать замедление в очередях. Мы настраиваем пороги и обрабатываем сигналы в разных сценариях, и в данном случае нам помогла автоматизация именно на этапе массового обновления порогов для всех КЕ. Ведь инцидент в нашей логике создаётся не для той конфигурационной единицы, по которой поступил сигнал, а для конфигурационной единицы услуги. Закрытие такого инцидента — тоже достаточно кастомный low-code сценарий: сначала он закрывает инцидент на исходной КЕ, затем ищет похожий инцидент (по хешу причины) среди открытых инцидентов на услуге и закрывает его, учитывая соответствующий набор параметров.
Как выглядит работа ситуационного центра сейчас?
Сейчас к Monq подключено уже около 50 ИС и порядка 850 КЕ, примечательно, что за 4 месяца мы подключили больше 40 систем на мониторинг. На этой стадии с платформой работает ситуационный центр.
С Monq мы выявляем предаварийные и аварийные инциденты, далее подключается встроенная автоматизация и идет процесс их устранения. Система показывает себя с положительной стороны.
Мы строим полноценный зонтик, который собирает всю информацию, автоматически ее обрабатывает и упрощает процессы и работу ситуационного центра.
Наш текущий тестовый контур состоит из порогов по полученным метрикам: метрики собираются либо напрямую или через агента с отдельных экспортеров из систем мониторинга, либо же по одному из контент-паков, как для того же Zabbix, например. То есть, как мы рассказывали выше, мы стараемся не принимать просто события из каких-то внешних систем, а генерируем сигналы на основе порогов, которые нам интересны. То же самое делаем и с данными автотестирования – их с помощью автоматизации перекладываем в метрики и уже из них собираем необходимые значения и выставляем пороги.
Сейчас ситуационный центр обрабатывает все события, появляющиеся в Monq. Главное достижение – высокая степень автоматизации. Если раньше предполагалось, что инженеры ситуационного центра вручную создавали чат, добавляли туда всех необходимых сотрудников, производили оповещение на пользователей и так далее, регистрировали инцидент в ITSM-системе, то сейчас же на момент инцидента у команды уже готов чат, туда уже добавлены все необходимые сотрудники, все необходимые обращения созданы, также отправлено оповещение на пользователей в случае, если произошли аварийные инциденты. Таким образом, текущая система автоматически регистрирует, закрывает инциденты, оповещает, плюс затягивают необходимую команду в чат.
Изменения во внутренних процессах: внедряем вместе
Внедрение подобных решений может вызывать вопрос: а что меняется в процессах и инструментах? В нашем случае, как первый шаг, мы зонтик смотрели для ситуационного центра, – соответственно, никаких ограничений на использование привычных инструментов мониторинга нет. Можно использовать и подключать к Monq и Zabbix, и Prometheus, и ELK и логи напрямую. Сам Monq не вносит никому никаких помех – если раньше мы всё передавали в Grafana, то теперь – в Monq. Более того, теперь с помощью ролевой модели мы сможем дать нужные доступы прикладным командам, и при этом не выдавать доступы в разрозненные Zabbix-ы, Prometheus-ы, – команды смотрят в единый инструмент, в котором комплексно собрана вся информация. Это удобно, когда все графики, логи, метрики находятся в одном месте – нам не надо лазить по семи разным системам – видим и настраиваем всё в едином пространстве. Как второй шаг, мы обучим команды центров компетенций работе с MONQ, которые параллельно с инженерами мониторинга смогут настраивать собственные мониторы.
Мы просто идем согласно той архитектуры, который была выработана раньше, при этом с помощью появляются новые функциональные возможности для реализации нашего подхода.
Важно также, что мы не сначала внедряем, а потом говорим командам поддержки и ситуационного центра, как этим пользоваться. Мы хотим сначала показать ценность от данного мониторинга и заинтересовать потенциальных пользователей, что можно делать не так, как сейчас, – то есть внедряем вместе с ними. То есть мы пошли от обратного – сначала попробовали, внедрили, поставили на мониторинг определенное количество систем, посмотрели, как это работает, поняли нюансы и с учётом уже последующих подключений готовим инструкцию – к концу внедрения у нас добавится еще один элемент во внутреннем руководстве по мониторингу, где мы опишем критерии, при каких условиях мы используем конкретно данную систему.
Итогом нашего опыта становится не только техническое решение, но и понимание того, насколько важны коммуникация и открытость в корпоративной среде. Внедрение зонтичного мониторинга — это не история о том, чтобы однажды настроить инструмент и поставить функционального заказчика или пользователей перед фактом. Напротив, мы стремимся к совместной работе внутренним клиентом на всех этапах: от первых концепций и архитектуры до непрерывного улучшения решений в ходе пилотирования и реальной эксплуатации. Такой подход позволяет учитывать реальные потребности, оперативно вносить коррективы и создавать продукт, который действительно помогает бизнесу, который приносит пользу, а не будет «еще одной ИС в реестре организации».
Не менее важно найти надёжного вендора, готового слушать и слышать своих клиентов, а при необходимости корректировать собственный роадмэп, ориентируясь на их конкретные задачи. Только при таком диалоге, при тесном и прозрачном взаимодействии мы получаем не просто инструмент, а ценный, развивающийся продукт, который становится устойчивым технологическим фундаментом для компании.
Над этой статьей мы работали втроём:
Михаил Полютин, руководитель направления операционного управления ИТ;
Денис Финогин, технический владелец системы, команда технического сопровождения и настройки Monq;
Виктория Чермошенцева, руководитель проекта по внедрению зонтичного мониторинга на ИТ-сервисах в компании НЛМК.