Алертинг и оповещения в мониторинге ИТ-инфраструктуры: настройка в Naumen Network Manager

В Naumen Network Manager (NNM) событие определяется как авария только при выходе за пороговые значения. Но чтобы оператор отреагировал, до него должно дойти уведомление.

В статье рассказали, как работает алертинг в мониторинге: как настраиваются нормальные значения метрик, уровни критичности, каналы оповещения и цепочки эскалации, а также методы снижения усталости от уведомлений.

Как Naumen NNM отличает аварии от нормальных значений

NNM держит связь со всеми элементами ИТ-инфраструктуры. Это позволяет системе фиксировать все события и любые изменения состояния устройств в режиме реального времени. Чтобы отличать штатную работу от аварий, NNM необходимы: знание нормальных значений метрик, возможность настройки пользовательских порогов и четкая классификация уровней критичности.

Нормальные значения. Система сопоставляет полученные показатели со стандартными и таким образом распознает аварии. В «коробочной» версии NNM по умолчанию заданы нормальные показатели метрик для  разных типов устройств. Они берутся из постоянно пополняемого каталога оборудования, в том числе российского.

Пользовательские пороги. Если у компании есть необходимость задать нормы для метрик, отличные от типовых, это можно сделать дополнительно. Благодаря low-code платформе, которая лежит в основе NNM, сделать это можно без разработчиков.

Уровни критичности. Задаются в списке аварий. Всего их пять: «Предупреждение», «Внимание», «Повреждение», «Авария», «Недоступен». Каждому соответствует свой цвет.

События могут быть в пределах нормальных показателей — значит, с объектом все в порядке. Если фиксируется выход за пороговые значения, событие классифицируется как авария.

Типы уведомлений в Naumen Network Manager

Пользователи NNM — это операторы мониторинга и специалисты, ответственные за различные объекты инфраструктуры. Операторы следят за функционированием системы, отслеживают аварии, регулярно проверяют полученные метрики. Сведения они получают через разные каналы оповещений.

Push-уведомления в интерфейсе

Этот способ помогает максимально оперативно донести информацию о критичных авариях. Всплывающее окно появляется на мониторе пользователя и сопровождается звуковым сигналом. Push-сообщения приходят не для всех обнаруженных ненормативных событиях, а только для тех, на которые настроены оповещения данного типа.

Вывод push-сообщения в интерфейсе системы не даст пропустить критичный сбой.

Список аварий

На отдельной вкладке NNM фиксируются все события, которые мониторинг классифицировал как аварийные. Это таблица с множеством данных: идентификация самой аварии, критичность, время и другие.

Список интерактивен. Контекстное меню позволяет перейти к карточке устройства, затронутого аварией, взять его в работу или оставить комментарий. При необходимости можно скорректировать правило, в соответствии с которым авария была классифицирована.

Список аварий удобен при многопользовательском режиме работы. Система фильтров позволяет показывать только те сведения, которые необходимы конкретному пользователю, и весь остальной массив информации не мешает.

Из интерфейса доступен переход в каждую карточку аварии. Это удобно, чтобы сразу узнать детали ситуации

Виджет «Топология»: визуальный алертинг

Здесь инфраструктура отображается в виде схемы, на которую нанесены объекты. Каждый обозначен иконкой. Если устройство работает нормально, то иконка зеленая. Если нет, иконка становится того цвета, который соответствует уровню критичности аварии.

Также виджет отражает группировку объектов по какому-либо признаку: месту, типу, ответственному. Каждой группе соответствует папка-контейнер. Иконка каждого контейнера окрашена в зеленый, если с его содержимым все в порядке. Если есть аварии, иконка окрашивается в цвет наиболее критичной из них.

Цветовое кодирование иконок в контейнере упрощает понимание, какое состояние у объекта

Виджет «ГИС»: геолокация аварий

Элементы инфраструктуры здесь показаны в контексте связей друг с другом и привязаны к геолокации в соответствии с координатами: широтой и долготой.

Как и на «Топологии», каждое устройство сопровождается иконкой, которая отражает состояние. Если уменьшать масштаб карты до размера, на котором показать все объекты этой локации станет невозможно, информация о них сгруппируется. Цветовая индикация на ней передаст данные о том, сколько устройств и в каком состоянии там находится.

Интерактивный виджет «ГИС» выводит показатели объектов с учетом локации на карте

Внешние уведомления: Email, SMS, Telegram

Эти способы оповещения позволяют сообщить об авариях пользователям, которые не находятся в системе мониторинга постоянно.

Такие уведомления гибко настраиваются по типу аварий, критичности, оборудованию, адресатам и другим параметрам. NNM содержит шаблон текста для этих сообщений, но у пользователей есть возможность редактировать их.

Триггеры по алертам с помощью отправки сообщений по почте, SMS или в мессенджер удобнее, если специалист находится вне рабочего места

Автоматическая цепочка уведомлений и эскалация

Инфраструктурный мониторинг и управление инцидентами в экосистеме Naumen выстроены как сквозной процесс: данные с оборудования автоматически становятся задачами для ИТ-службы.

Так взаимодействуют решения Naumen при мониторинге инфраструктуры и оповещении при сбоях

Рассмотрим подробнее, что происходит на каждом участке этой цепочки: какими сведениями оперирует каждая система, как их обрабатывает и передает на следующий этап.

Шаг 1. Сбор данных об инфраструктуре в Naumen Network Manager

NNM напрямую собирает данные с элементов инфраструктуры: серверов, сетевого оборудования, систем хранения данных. При возникновении нештатной ситуации (например, SMART-ошибки на диске) NNM регистрирует событие.

Naumen Network Manager позволяет не ограничиваться разовыми уведомлениями, а умеет выстраивать из них последовательные цепочки. Для этого он содержит графический редактор, в котором задается логика и правила оповещения для различных аварий.

Например, на событие настроены уведомления адресату в Telegram. Если спустя полчаса в системе не появилась отметка о том, что оно «Принято в работу», уведомление отправляется снова — уже в SMS, и например, дублируется еще одному специалисту. Таких звеньев в цепочке может быть несколько, и они могут в обозначенных случаях запускать автоматические действия, например, скрипт или перезагрузку оборудования.

Цепочка правил гибко настраивается в графическом редакторе под нужные процессы мониторинга

Шаг 2. Оценка влияния на бизнес в Naumen BSM

Система зонтичного мониторинга получает событие от NNM и накладывает его на ресурсно-сервисную модель — схему того, как элементы инфраструктуры связаны с какими бизнес-сервисами. Naumen BSM определяет, какой сервис пострадает, какие смежные устройства будут затронуты, какова критичность инцидента для бизнеса.

Ресурсно-сервисная модель объединяет системы корневого и зонтичного мониторинга

Шаг 3. Автоматическое создание инцидента в Naumen Service Desk

На основе оценки мониторинга в  решении Naumen Service Desk автоматически создается инцидент с заполненными полями: описание проблемы, критичность, затронутый сервис, возможные последствия. Ответственный специалист получает задачу без ручного ввода данных. Таким образом из цепочки исключен человеческий фактор и любые задержки в передаче данных.

Если инцидент не решен в установленное SLA время, система автоматически повышает приоритет и переводит задачу на вышестоящий уровень поддержки. Правила эскалации настраиваются в Service Desk.

В заявку на устранение неисправности автоматически добавляется вся необходимая информация об оборудовании

Усталость от уведомлений: риски и методы снижения нагрузки на операторов

В сервисной компании, обслуживающей интернет-эквайринг для розничных сетей, система мониторинга генерировала в среднем 50 алертов в час. Большинство из них — некритичные отклонения, которые не требуют немедленной реакции, например, повышение температуры в стойке сервера на 5 градусов от пороговой метрики. Операторы привыкли, что большинство сигналов можно игнорировать, и перестали проверять каждый. В этом потоке затерялся критический инцидент — отказ платежного шлюза одного из клиентов. Его обнаружили только через 15 минут. За это время не прошло около 1,5 тыс. транзакций.

К этой ситуации привела усталость от уведомлений (alert fatigue). Она возникает при превышении пропускной способности оператора к обработке входящих сигналов. В результате сотрудники начинают пропускать алерты или реагировать на них с задержкой. Рост доли ложных и дублирующих уведомлений прямо коррелирует с вероятностью пропуска критического события.

Чтобы не пропускать важные уведомления, используются следующие методы снижения нагрузки.

Подавление дублей. Система мониторинга должна распознавать повторяющиеся события и генерировать только одно уведомление. Последующие дубли блокируются на заданный интервал времени.

Корреляция событий. Связанные алерты (например, отказ сетевого устройства и потеря доступности всех сервисов за ним) группируются в один инцидент. Это уменьшает количество уведомлений и предоставляет оператору целостную картину проблемы.

Приоритизация по критичности. Алерты разделяются на уровни. Каждому их них соответствует своя цветовая маркировка и требуемое время реакции. Критичные события не могут быть проигнорированы.

«Тихие часы». В периоды низкой активности (ночное время, выходные дни) система ограничивает доставку некритичных уведомлений. Такие алерты накапливаются и предоставляются оператору сводкой в начале рабочего дня.

Тестирование правил на стенде. Новые пороги срабатывания и политики оповещения проходят валидацию на тестовом контуре до внедрения в продуктивную среду. Это предотвращает как пропуск инцидентов, так и зашумление операторов.

Скорректировать нагрузку помогает ключевой показатель — количество алертов на одного оператора в смену. Рекомендуемый диапазон — не более 5–10 значимых уведомлений в час. Превышение этого значения требует пересмотра настроек мониторинга.

Усталость от уведомлений является следствием неоптимальной конфигурации систем мониторинга, а не недостаточной дисциплины персонала. Задача ИТ-подразделения — настроить фильтрацию, группировку и приоритизацию алертов таким образом, чтобы оператор получал только события, требующие вмешательства, в объеме, соответствующем его пропускной способности.

Как настроить алертинг

Системы алертинга необходимо настраивать, чтобы сырой поток событий от систем мониторинга оформлялся в осмысленные уведомления. С ними оператору будет проще работать.

Ниже приведен порядок действий, которого требует настройка уведомлений в системе мониторинга.

Алертинг непрерывно улучшается, адаптируется к инфраструктуре и становится точнее с каждым циклом

Настройка алертинга — это циклический процесс, требующий регулярной корректировки на основе анализа ложных срабатываний. В NNM настройка порогов, каналов уведомлений и цепочек эскалации также выполняется через интерфейс без написания кода.

К выводам

Система уведомлений в Naumen Network Manager позволяет настраивать различные варианты алертов об авариях на объектах ИТ-инфраструктуры. Это гарантирует, что аварию своевременно заметят ИТ-специалисты и примут меры, чтобы минимизировать негативные последствия.

Что еще интересного