AIOps поверх Zabbix и SIEM: как автокорреляция меняет работу дежурного инженера

Несколько месяцев назад к нам пришёл запрос от клиента - производственная компания, объект КИИ, смешанная инфраструктура: Zabbix для мониторинга железа и сетевых устройств, MaxPatrol SIEM для событий безопасности, всё это без единой точки корреляции. Дежурный инженер утром разгребал два интерфейса параллельно и пытался в голове соединять события из разных систем. Задача звучала просто: поставить AIOps-движок поверх, чтобы он это делал сам. На деле - несколько месяцев работы, несколько неожиданных выводов и одно принципиальное наблюдение про природу ложных срабатываний.

Почему не хватало двух систем по отдельности

Zabbix у клиента работает давно, настроен плотно, покрытие хорошее. SIEM - относительно свежий, после обязательств по КИИ. Проблема не в том, что каждая система работала плохо - обе работали нормально по отдельности. Проблема в том, что один и тот же инцидент в инфраструктуре порождал события в обеих системах, никак не связанные между собой.

Типичный сценарий: один из серверов начинает деградировать. Zabbix видит рост latency дисков и cpu iowait - три алерта. SIEM параллельно видит аномальную активность процессов на том же хосте - ещё два события. Дежурный получает пять уведомлений, которые на экране выглядят как пять независимых проблем. Разбираясь с первым алертом из Zabbix, он может не заметить, что все пять - об одном и том же.

Число вот таких «веерных» инцидентов в среднем дежурстве - в районе 20-30% от общего потока. Не критично само по себе, но это именно та нагрузка, которая постепенно притупляет внимание.

Что поставили и как интегрировали

Выбирали между несколькими вариантами - как зарубежными (BigPanda, Dynatrace Davis AI), так и более близкими к отечественному стеку решениями. В итоге остановились на Zabbix Problem Correlation в связке с внешним корреляционным движком на базе OpenSource-оркестратора, который умеет принимать события из нескольких источников через webhook и строить граф связанных событий.

Интеграция по источникам:

• Zabbix отдаёт события через media type webhook в реальном времени - стандартный механизм, ничего изобретать не пришлось.
• MaxPatrol SIEM - экспорт через REST API по расписанию, раз в минуту. Идеально было бы тоже через webhook, но API SIEM в версии, стоящей у клиента, не поддерживал push-модель - пришлось pull.
• Сетевое оборудование - отдельный Zabbix-прокси, события приходят через тот же канал.

Движок получает поток событий, строит кластеры по нескольким признакам: временна́я близость (события в одном окне), общий хост или подсеть, категория события (performance / security / availability). Если события попадают в один кластер - дежурный видит один инцидент с вложенными событиями, а не пять отдельных алертов.

Что изменилось для дежурного

Это самое интересное - и самое неочевидное до начала.

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

Контекст стал видимым. Раньше, открывая алерт по дисковой latency, инженер должен был сам идти в SIEM и смотреть, нет ли там чего-то на том же хосте. Теперь SIEM-события уже приложены к карточке. Звучит как мелочь - на практике это несколько минут к каждому инциденту, которые умножаются на смену.

Приоритизация стала осмысленнее. Если к инциденту прикреплены события и из мониторинга производительности, и из SIEM, - движок автоматически поднимает приоритет. Чисто технический сбой и сбой с признаками аномальной активности разделены. Это не заменяет оценку инженера, но даёт правильный стартовый фрейм.

Про ложные срабатывания честно

Первые две недели были болезненными. Количество ложных объединений - когда движок кластеризовал события, которые реально не связаны - оказалось выше ожиданий. Движок корреляции не знает семантики инфраструктуры: что ночной бэкап создаёт активность на всём хранилище одновременно, что конкретный хост всегда шумит в определённые часы, что два события из одной подсети не обязательно об одном инциденте.

Настройка заняла около месяца. Что помогло:

• Временные исключения для регулярных задач - ночные бэкапы, плановые репликации, скрипты аналитики, выведены в отдельный шаблон корреляции с пониженным весом.
• Уточнение окна корреляции - дефолтное значение в несколько минут оказалось слишком широким для части сценариев. Для сетевых событий сузили, для производительности - оставили.
• Ручная разметка первые две недели: дежурный отмечал каждый неверно объединённый инцидент, это шло в feedback для настройки весов.

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

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

Где мы сейчас

Система работает в production три месяца. Итоговая оценка клиента - умеренно положительная, без эйфории. Корреляция реально снижает нагрузку на дежурного и делает работу со смешанным мониторингом/SIEM-стеком удобнее. Но это не «умный мозг», который сам разбирается в инцидентах - это инструмент агрегации, который хорошо работает после ручной настройки под конкретную инфраструктуру.

Следующий шаг, который обсуждаем с клиентом - подключение к тому же движку данных из ML-аномалий Zabbix 7.4. Логика: если аномалия на хосте и событие в SIEM появились в одном временном окне - это совсем другой приоритет, чем каждое из них по отдельности.

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