Упал интернет-магазин? Мониторинг бизнес-сервисов Monq поможет найти причину
Привет, Хабр! В этой статье рассмотрим, как корпоративный ИТ-мониторинг Monq отслеживает работоспособность ИТ-систем предприятия, облачных сервисов и коннекторов с внешними поставщиками, такими как системы оплаты, логистики, бронирования товаров или билетов, а также в других сферах. Real-time мониторинг инфраструктуры и работоспособности ИТ-инфраструктуры бизнеса критически важен для функционирования электронной торговли, ритейла, промышленности, банкинга и страхования, медклиник и госучреждений.
***
Дисклеймер: Мы знаем, что на Хабре не любят «продающие» статьи вендоров. И эта статья, прежде всего — о функциональности продукта. В линейке Monq есть комьюнити-версия, которая имеет ряд ограничений, но ее лицензия бесплатна. Описанный в статье кейс можно реализовать на комьюнити версии.
Если вы в компании отвечаете за мониторинг, доступность цифровых сервисов или эксплуатацию, ищете замену западным решениям и еще ничего не слышали о Monq, то рекомендуем нашу статью на Хабре Новый Monq 8.0 — российский all-in-one мониторинг на low и no-code автоматизации: обзор возможностей и «невозможностей». Это довольно детальный рассказ о том, что Monq умеет и что не умеет.
Теперь о важности мониторинга бизнес-сервисов
Представьте ситуацию: крупный интернет-магазин, который ежедневно посещают тысячи клиентов, внезапно перестает нормально функционировать. Посетители уже некоторое время не могут оформить заказы, но админы узнают об этом сбое с задержкой, получив информацию только после обращений клиентов в техподдержку. Возможна и обратная ситуация, когда существующая корпоративная система распознает сбой, но начинает забрасывать админов потоком алертов, из которых трудно оперативно выяснить истинную причину сбоя и быстро пофиксить проблему.
Для таких ситуаций мы рекомендуем попробовать коммьюнити версию Monq — корпоративную систему ИТ-мониторинга, которая автоматически построит дерево зависимостей между компонентами ИТ-инфраструктуры и отследитт их состояние, помогая быстро находить первопричину сбоев. Далее, по мере охвата мониторингом большего числа хостов и бизнес-процессов, можно перейти на расширенную версию.
В России нет сборной статистики по убыткам интернет-магазинов, ассоциированных со сбоями ИТ-инфраструктуры. Скорее всего, такой статистики по РФ никто не ведет. Однако есть довольно впечатляющие цифры в зарубежных источниках. Считается, что в зависимости от размера магазина, числа посетителей и других факторов, один час простоя интернет-торговли у крупных ритейлеров может стоить от $300,000 до более чем $1 миллиона. В исследовании 2022 года от ITIC, 44% компаний сообщили, что час простоя обходится им более $1М (Uptime Institute).
Кстати, у этой статьи есть видео-версия на YouTube. Если вам удобнее смотреть в видео-формате, велком сюда: https://youtu.be/i84nDbdPa5o.
Давайте продолжим. В системе Monq все элементы инфраструктуры представлены как конфигурационные единицы (КЕ), которые взаимосвязаны между собой. Как это выглядит — вот пример списка КЕ на Рис. 1. Конфигурационные единицы (КЕ) в Monq могут включать бизнес-сервисы, виртуальные машины и даже порты коммутаторов.
Далее, у нас есть«Оперативный центр» — это ключевой инструмент, который предоставляет администраторам полную картину по каждой КЕ, отображая как текущее состояние, так и влияние на другие компоненты системы. Это позволяет контролировать крупные и разрозненные ИТ-окружения, где могут быть задействованы тысячи элементов, и получать комплексное представление о работе инфраструктуры.
Рис. 1. Пример списка конфигурационных единиц в Monq
Объекты КЕ создаются в базе данных CMDB и автоматически добавляются в ресурсно-сервисную модель (РСМ) с помощью low-code сценариев автодискаверинга. Этот процесс значительно упрощает настройку мониторинга, так как ручное создание и управление тысячами КЕ, которые обычно встречаются у компаний, было бы крайне трудоемким. Множество сценариев доступно «из коробки», и при этом возможно использование low-code сценариев для реализации собственной логики управления РСМ, если стандартные интеграции оказались недостаточны.
CMDB (Configuration Management Database) в системе мониторинга — это база данных, которая хранит информацию о конфигурационных единицах (КЕ) ИТ-инфраструктуры. Эти единицы могут включать серверы, приложения, сетевое оборудование, виртуальные машины и другие компоненты, критически важные для функционирования ИТ-системы. Обобщая, CMDB является ключевым компонентом для проактивного управления ИТ-сервисами, снижая риски простоев и помогая быстрее находить и устранять первопричины сбоев.
Роль CMDB в системе мониторинга Monq:
Единое представление о состоянии ИТ-инфраструктуры (централизация данных). CMDB хранит полную информацию о всех конфигурационных единицах и их взаимосвязях. Это помогает создать единое представление об ИТ-инфраструктуре, находящейся под мониторингом Monq.
Автоматизация управления в виде интеграции CMDB с системой мониторинга для отслеживания изменений в конфигурациях, что позволяет оперативно выявлять отклонения и инциденты.
Поддержка РСМ-модели через построение в CMDB зависимостей между компонентами, что позволяет оценить влияние состояния инфраструктуры на бизнес-процессы.
Как работает корпоративный мониторинг Monq
Представим, как ресурсно-сервисная модель помогает отслеживать взаимосвязи в ИТ-инфраструктуре на конкретном примере. Оперативная карта (Рис. 2) отображает ключевые бизнес-сервисы крупной розничной сети, которые составляют основу всех процессов — от выбора до оплаты и доставки товаров.
Оперативная карта — это такая верхнеуровневая структура, на которой видно, как один объект влияет на другие через цепочки связей. В нашем примере карта показывает нормальное состояние бизнес- и ИТ-процессов, где все компоненты функционируют на 100%, но такие идеальные условия бывают не всегда, и система мониторинга готова оперативно обнаружить возможные сбои.
Рис. 2. Пример РСМ-модели бизнес-сервисов в крупной ритейл-сети
Далее рассмотрим случай нештатной ситуации — в системе мониторинга были зафиксированы два оповещения в аварийных чатах, указывающих на инцидент первого приоритета в сегменте «Онлайн-магазин». Сбой такого уровня, как правило, означает полную недоступность услуги, что напрямую влияет на ключевые бизнес-процессы.
На тепловой карте состояния системы (Рис. 3) можно наблюдать значительное снижение уровня работоспособности до 40%, что свидетельствует о том, что большая часть клиентов не может воспользоваться сервисами.
Рис. 3. Пример тепловой карты состояния системы при сбое ключевого компонента
Для детального изучения проблем, возникших в ИТ-инфраструктуре, Monq предоставляет инструмент анализа первопричин, упрощая работу админов и инженеров техподдержки. В данном случае, используя грамотно построенную карту ресурсно-сервисной модели (Рис. 4), можно определить, что причиной инцидента является полная недоступность услуги «Оплата товаров». Для подтверждения этого факта был проведен анализ первопричин, начиная с анализа верхнеуровневой конфигурационной единицы.
Рис. 4. Карта ресурсно-сервисной модели с индикацией источника сбоя
Состояние основной конфигурационной единицы (КЕ) включает в себя несколько компонентов, и в данном примере компонент «Розничные продажи» находится на критическом уровне. Используя инструмент детализации данных, можно уточнить сущность проблемы, пройдя все дерево зависимостей до уровня первичного инцидента (Рис. 5).
Рис. 5. Компонент «Розничные продажи» находится на критическом уровне
Процесс анализа первопричин определяет влияние инцидентов на состояние выбранной КЕ (Рис. 6) и выводит полный список инцидентов, вызвавших нарушение в работе бизнес-процессов.
Рис. 6. Анализ первопричин сбоя
Вот чуть подробнее о том, как происходило информирование админов. Анализ показал поступление нескольких алертов в одно и то же время:
1. Первый сигнал был вызван проваленными сборками синтетического мониторинга, информирующими, что страницы оплаты товаров перестали загружаться.
2. Второй сигнал был зафиксирован в связи с превышением пороговых значений на одном из узлов инфраструктуры.
3. Третий сигнал поступил из внешней системы мониторинга, при этом количество событий было значительным.
Система Monq автоматически подавила избыточные сигналы (п.3), сгенерировав один сигнал с привязкой остальных как вложенной информации. Это демонстрирует работу механизмов дедупликации и корреляции событий в Monq, что предотвращает перегрузку экрана алертами и позволяет админам обрабатывать сгруппированные события, не разбирая каждый по отдельности (Рис. 7).
Рис. 7. Пример алертов на экране оперативного центра
Алерты содержат дополнительную информацию о первопричинах, ссылки на ресурсы для дальнейшего расследования, а также сведения о бизнес-процессах, затронутых и/или инициированных в результате этих событий. В данном случае сработал процесс, уведомляющий об аварии и запустивший правило эскалации, которое выделяет ограниченное время на устранение инцидента до перехода на следующий этап.
Рис. 8. Так выглядит pipeline бизнес-процессов в Monq
Анализ инцидента показал, что первопричиной явилась проблема на одном из контейнеров (Pod), обслуживающих сервис оплаты товаров. После выявления проблемы происходит оперативное уведомление ответственных сотрудников (или подразделения) и автоматически создается тикет в системе сервис-деск для дальнейшей обработки.
Зонтичный мониторинг Monq объединяет данные из множества разрозненных источников на одном экране, позволяя контролировать всю ИТ-инфраструктуру компании. Представленное на рынке специализированное ПО типа «Зонтик» от разных вендоров, как правило, собирает уже готовые события/алерты с Zabbix, Prometheus, SCOM и других систем. В отличие от конкурентов, Monq умеет собирать как готовые алерты, так и работает с сырыми данными в том числе.
Система собирает метрики и события, анализирует их и визуализирует для оценки «здоровья» сервисов и расчета SLA. Одной из ключевых функций является защита от «шторма алертов», которая автоматически группирует и фильтрует уведомления, снижая шум и помогая быстрее находить причины сбоев. Это также помогает бизнесу понимать, как нехватка ИТ-ресурсов (CPU, GPU, СХД, памяти и др.) влияет на стабильную работу ключевых сервисов.
Применение сервиса отчетов по событиям мониторинга
Для контроля за качеством предоставляемых услуг в системе мониторинга Monq предусмотрен сервис отчетов. Этот инструмент позволяет создавать шаблоны отчетов и генерировать их по интересующим сервисам за заданный период времени (Рис. 9). Отчеты могут быть автоматически отправлены на электронную почту в виде файлов.
Рис. 9. Экран с отчетом о состоянии ИТ-инфраструктуры
Уточню, что модуль «Отчетов» в Monq позволяет настроить различные шаблоны отчетов в системе:
Отчет «Доступность» — это отчет о доступности информационной системы в целом с 3-мя уровнями детализации. Админ или инженер техподдержки может получить сведения о доступности КЕ, информационных систем (ИС), состоящих из КЕ или о доступности сложных ИС, состоящих из множества подсистем.
Отчет «Доступность (мультиотчет)» — отчет о доступности сложной системы, который включает в себя показатели отчета о доступности системы в целом и каждой из подсистем в ее составе. В мультиотчет по подсистемам выводятся сведения о времени сервисного обслуживания подсистемы, рабочем и нерабочем времени подсистемы, проценте и времени доступности подсистемы, максимальном простое, а также другие показатели, включая соблюдение SLA.
Среди показателей в отчете — SLA как один из самых важных. На его основе можно проводить контроль подрядчиков, увидеть картину внутренних процессов, как работают ваши сотрудники. Так как неважно работал ли сервер меньше на 5 мин в неделю или нет, важнее как чувствовали себя клиенты и были ли они в целом удовлетворены качеством сервиса.
Заключение
В заключение еще раз назовем функциональные возможности системы Monq, обеспечивающие целостную работу процесса мониторинга — начиная с процесса сбора и обработки данных и до автоматизированного управления инцидентами и оценки «здоровья» объектов.
Основу работы системы составляет обработка потоков данных, включающая события из внешних систем мониторинга (Zabbix, Prometheus и др.), события об изменениях топологии, прием сырых логов и метрик, которые в дальнейшем преобразуются в сигналы и благодаря которым происходит автоматическое управление ресурсно-сервисной моделью (РСМ). Иными словами, на основе событий возможно формирование алертов внутри системы, работая как с сырыми данными, так и агрегировать уже готовые события из внешних систем, создавать по ним сигналы и привязывать к КЕ. Важным компонентом системы является модуль синтетического мониторинга, который обрабатывает автотесты и также выступает источником для создания сигналов. Примером такого сигнала может быть рассмотренный выше инцидент в работе сервиса оплаты.
Для описания ИТ-инфраструктуры компании и подготовки логики мониторинга, система Monq оснащена движком low-code автоматизации, который позволяет реализовывать как простые сценарии, так и более сложные, в зависимости от требований. Эти сценарии могут быть полноценной заменой нескольким сервисам и адаптируются под потребности компании без необходимости ожидания релизов от вендоров. Кроме того, Monq предлагает несколько типовых решений «из коробки», таких как интеграция с популярными системами мониторинга (Zabbix, Kubernetes, Prometheus и др.) и использование готовых контент-паков, что значительно упрощает процесс настройки мониторинга и автоматизации.
Также стоит отметить, что в новой 8-й версии Monq реализована поддержка упрощенных бизнес-процессов, которые представляют собой автоматизированные пайплайны для выполнения задач, таких как нотификации дежурных служб, создание тикетов в сервис-деске, интеграции с внешними системами и построение цепочек эскалации.
Вы всегда можете скачать комьюнити-версию продукта и попробовать построить мониторинг для оценки качества продукта. А когда у вас появятся вопросы и собственное мнение о продукте, наша команда ответит на вопросы и поможет развернуть работу мониторинга Monq на всей ИТ-инфраструктуре компании.
Обращайтесь на почту askformonq@monqlab.com или если что-то не будет получаться или возникнут другие вопросы— велком в наше комьюнити в Telegram.
