В современном ИТ-ландшафте, где сложность распределенных систем растет экспоненциально, способность своевременно фиксировать изменения состояния сервисов становится критическим фактором обеспечения доступности. Такую способность обеспечивает практика мониторинга и управления событиями (Monitoring & Event Management) это фундаментальный элемент управления услугами, позволяющий организации перейти от реактивного «пожаротушения» к управлению инфраструктурой на основе данных.

Назначение, задачи и основные понятия практики

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

К ключевым задачам практики можно отнести:

• раннее обнаружение аномалий и отклонений;

• прогнозирование потенциальных сбоев до того, как они повлияют на бизнес;

• предоставление контекстной информации для групп реагирования;

• верификацию корректности работы автоматических скриптов восстановления.

Центральное понятие данной практики, её объект управления — событие (event). В ITIL событие определяется как любое значимое изменение состояния конфигурационной единицы (CI) или ИТ-услуги, регистрируемое инструментарием мониторинга. События классифицируются по важности:

• Информационные — фиксация штатных операций (запуск резервного копирования).
• Предупреждения — выход метрики за «желтую» зону, не влияющий на производительность, но требующий внимания.
• Критические — отклонение, требующее немедленной реакции.

По причине возникновения события делятся на четыре типа:

• Доступности (Up/Down) — фиксация факта, что узел или сервис перестал отвечать.
• Производительности (Threshold) — срабатывание при превышении порогов CPU, памяти, задержки ответа API.
• Безопасности (Security) — неудачные логины, подозрительный трафик, изменение критических конфигураций (обычно интегрируются с SIEM).
• Бизнес-события (Business events) — например, «количество заказов в час упало на 90%» (мониторинг результата работы ИТ для бизнеса, а не железа).

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

Важно различать ошибку (Error) — внутреннее техническое состояние CI (например, поврежденный сектор диска) — и событие — факт обнаружения этой ошибки системой мониторинга. 

Инцидент возникает, когда оператор или корреляция подтверждает, что событие уже влияет на услугу (например, «потерян массив RAID5»).

Процессы и виды деятельности

Жизненный цикл события включает четыре этапа:

1. Обнаружение — сбор метрик через агентов, SNMP-трапы, Syslog или API.
2. Корреляция — анализ событий во времени и пространстве (объединение 100 предупреждений о недоступности серверов в один инцидент отказа коммутатора).
3. Фильтрация — отсев дубликатов и информационных событий, не требующих реакции.
4. Эскалация — принятие решения: автоматическое действие (авто-ремедиация), регистрация инцидента или создание запроса на изменение.

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

Активный мониторинг (синтетический)

В этом подходе система самостоятельно генерирует тестовые транзакции, имитируя действия реального пользователя.

Примеры:

• ICMP-проверка (ping) — каждые 30 секунд отправляется запрос к сетевому шлюзу; если ответа нет — фиксируется событие «недоступность узла».

• HTTP-проверка (synthetic browser) — раз в минуту бот открывает страницу авторизации, вводит тестовый логин/пароль и проверяет, появилась ли кнопка «Личный кабинет».

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

Реактивный мониторинг (реагирование на факт)

В отличие от активного, здесь система ждет, пока произойдет реальное событие (ошибка, сбой, исключение), и только тогда генерирует сигнал.

Конкретные примеры:

• HTTP 500 ошибка — пользователь открыл сайт, сервер вернул ошибку, веб-сервер пишет в лог, и агент мониторинга отправляет алерт.

• Отказ транзакции — клиент пытается оплатить заказ, платежный шлюз возвращает ошибку по тайм-ауту; система мониторинга фиксирует событие.

• Краш процесса — демон базы данных аварийно завершился, ОС записала сообщение в syslog, и триггер алерта сработал.

Когда применять: для обнаружения проблем, которые уже повлияли на пользователя. Основной недостаток — сигнал возникает постфактум, когда ущерб уже нанесен.

Пассивный мониторинг (сбор без вторжения)

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

Примеры:

• Анализ netflow/sflow — сетевой коммутатор отправляет метаданные о всех проходящих через него пакетах (без содержимого). Система выявляет аномалии: внезапный рост трафика на нестандартном порту.

• Пассивный RUM (Real User Monitoring) — на веб-страницу вставлен JS-скрипт, который собирает время загрузки каждого ресурса для всех реальных пользователей, без генерации тестовых запросов.

• Анализ логов через ELK — в кластер стекаются логи всех сервисов; система ищет паттерны «ошибка подключения к БД» без настройки явных порогов.

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

Проактивный мониторинг (прогнозный)

Наконец, самый современный подход. Система анализирует тренды и предсказывает будущий сбой до того, как произойдет ошибка. Как правило, он использует ИИ и машинное обучение.

Конкретные примеры:

• Прогноз заполнения диска — система ежедневно измеряет рост занятого пространства. Если по линейной регрессии до полного заполнения осталось 5 дней, генерируется предупреждение «Требуется расширение тома».

• Предсказание отказа диска — анализ S.M.A.R.T.-атрибутов (Reallocated Sectors Count, Spin Retry Count) позволяет с вероятностью 95% предсказать выход HDD из строя за 7–10 дней.

• Аномалия на основе сезонности — ИИ-модель знает, что в пятницу вечером нагрузка на биллинг выше на 40%. Если в пятницу нагрузка выросла на 80% — это аномалия, требующая проверки, хотя критический порог еще не достигнут.

Когда применять: для инфраструктуры с высокими требованиями к доступности (SLA 99.99%), где недопустимы простои даже на несколько минут.

Оптимальная практика, как правило, требует комбинации всех четырех подходов: активные проверки доступности + реактивный анализ ошибок + пассивный сбор метрик + проактивное прогнозирование на основе ИИ.

Ключевые показатели и метрики

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

Кроме того, для проактивного мониторинга добавляется метрика «Количество предотвращенных инцидентов» — число сбоев, которых удалось избежать благодаря прогнозу ИИ.

Инструментальная поддержка и преимущества ИИ

Что касается инструментария, то здесь сложился определенный стандарт. Для сбора метрик де-факто стандартом стал прометей-совместимый стек (Prometheus + Grafana + Alertmanager). Для обработки логов (реактивный и пассивный мониторинг) используются ELK/OpenSearch. Активный мониторинг доступности реализуется Blackbox exporter или внешними сервисами (UptimeRobot, Pingdom). Крупные организации внедряют APM-системы (Dynatrace, New Relic) для трассировки транзакций между сервисами.

Особого внимания заслуживает внедрение технологий искусственного интеллекта (ИИ) в контур мониторинга и управления событиями. Оно дает следующие стратегические преимущества:

• Интеллектуальная корреляция событий. ИИ-алгоритмы выявляют скрытые причинно-следственные связи между событиями, которые человек или детерминированные правила могут пропустить. Например, модель может обнаружить, что предупреждение о микрозадержках в сети за 15 минут до сбоя базы данных является ранним предиктором отказа.

• Динамическое управление порогами (adaptive thresholds). В отличие от статических порогов (CPU > 90%), ИИ анализирует сезонные и суточные паттерны нагрузки. Система автоматически подстраивает чувствительность мониторинга под пиковые часы или ночные окна обслуживания, резко снижая уровень шума до <10%.

• Прогностическая аналитика (Predictive Analytics). ИИ не просто фиксирует текущее состояние, а прогнозирует будущие сбои на основе трендов. Например, анализ скорости роста занятости дискового пространства позволяет сгенерировать предупреждение за 7 дней до полного заполнения, превращая аварийный инцидент в плановую операцию.

• Автоматическое устранение типовых инцидентов (AIOps). Интеграция ИИ с системами оркестрации позволяет не только рекомендовать действие, но и автоматически выполнять проверенный скрипт восстановления. Со временем нейросетевая модель обучается на успешных кейсах, повышая показатель auto-remediation rate до 50–70%.

• Семантический поиск по логам. ИИ-модели (на базе LLM) позволяют задавать вопросы на естественном языке: «Покажи все ошибки аутентификации за последний час у пользователей из офиса в Москве» — без необходимости изучать синтаксис языка запросов (KQL, Lucene).

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

Сравнительная таблица подходов

Применение KPI и выбор инструмента зависят от импользуемого подхода. Сравнение подходов к мониторингу приведено в таблице:

Заключение

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

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую