Один реальный сбой редко порождает один алерт. Если падает сетевой uplink, система мониторинга может одновременно сообщить о недоступности узла, ошибках HTTP-проверок, остановке приложений и отказе бизнес-сервисов. Для инженера это один инцидент, но для системы мониторинга — несколько независимых событий.

Меня зовут Антон Касимов, я работаю в Gals Software, веду телеграм-канал Zabbix Recipes, посвященный Zabbix, где делюсь своим опытом. Сегодня поговорим про новый функционал в Zabbix 8.0 — Complex Event Processing (CEP). Этот механизм обрабатывает поток событий по правилам, сохраняет выбранные события во временных окнах и выполняет над ними операции в заданные моменты времени.

CEP позволяет:

• группировать события по хосту, тегу, IP-адресу, сервису или другому контексту;

• ограничивать окно временем и количеством событий;

• связывать первое событие с последующими как причину и симптомы;

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

• находить более сложные последовательности с помощью JavaScript.

Что было до CEP

Для начала давайте отделим новый механизм от уже существующих.

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

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

Причины и симптомы позволяют явно показать, какая проблема является причиной, а какие — её симптомы. До CEP такие связи формировались вручную.

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

Из чего состоит правило CEP

Правило можно представить как конвейер, состоящий из трех основных компонентов:

1. Условия отбора. Можно фильтровать события по имени, критичности, хосту, группе хостов, тегам и их значениям.

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

3. Операции. Они выполняются в определённых точках жизненного цикла события и окна.

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

Пять режимов обработки

В Zabbix существует пять режимов CEP, которые представлены в таблице ниже.

Без окна (None)

Самый простой режим. Не создаёт окно и не хранит состояние. Событие обрабатывается сразу. Такой режим подходит для обогащения: например, всем проблемам приложения добавить team:applications или привести критичность к принятой в компании шкале.

Simple multiple (простое: несколько)

Событие может попасть во все подходящие правила этого режима. Например, одно правило добавит владельца сервиса, а второе поместит событие в окно и автоматически закроет его после истечения TTL.

Simple once (простое: одно)

Событие обрабатывает только первое подходящее правило Simple once. Это похоже на цепочку if / else if: более точные условия должны находиться выше, а общее правило — ниже.

Причина и симптомы (Cause and symptoms grouping)

Первое событие в фиксированном окне становится причиной, остальные — симптомами до закрытия фиксированного окна. Закрытие окна само по себе не восстанавливает проблемы.. Причине можно добавить счётчик симптомов. Это сокращает число независимых проблем в интерфейсе и помогает оператору начать анализ с предполагаемой первопричины.

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

Поиск шаблона (Pattern match)

В этом режиме JavaScript получает текущий набор событий окна через cep_get_events() и проверяет нужное условие: число событий, их теги, имена, критичность, время и состояние. Скрипт возвращает строку true или false. Сам скрипт не меняет события — при результате true запускаются настроенные операции Pattern matched.

Как работают временные окна

Окно — главная отличительная черта CEP. У него есть три важных параметра:

Длительность задаёт, сколько времени событие участвует в обработке. Момент истечения рассчитывается от исходного времени события. В простых режимах окно скользящее: разные события могут истекать в разное время. В режиме причины и симптомов окно фиксированное.

Ёмкость ограничивает число событий. Если окно заполнено, новое событие не добавляется, но для него всё равно может сработать точка Event evicted. Это позволяет реализовать защитную реакцию на переполнение: закрыть повтор, понизить его критичность или добавить специальный тег.

Группировка определяет, какие события делят одно состояние. Без группировки правило использует общее окно. Если выбрать хост, группу хостов или тег, для каждого значения образуется отдельное окно. Для попыток входа логичным ключом будет source_ip, для резервного копирования — backup_job_id, а для флапа интерфейсов — тег с портом.

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

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

Пять точек выполнения операций

Операции привязаны к моментам жизненного цикла:

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

Какие изменения можно вносить в события

CEP позволяет:

• изменить имя события;

• установить, повысить или понизить критичность;

• добавить, переименовать или удалить тег;

• установить, увеличить или уменьшить числовое значение тега;

• подавить или вернуть событие из подавления;

• закрыть проблему;

• отбросить событие;

• клонировать первое или последнее событие окна;

• закрыть окно.

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

Практический пример: три неудачных входа

Рассмотрим правило «три неудачных входа с одного адреса за пять минут».

1. Отбор и группировка

Правило выбирает события неудачной аутентификации, создаёт пятиминутное окно и группирует его по тегу source_ip.

2. Проверка шаблона

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

Упрощённая логика выглядит так:

const events = cep_get_events();
let attempts = 0;

for (const event of events) {
    if (!event.is_copied) {
        attempts++;
    }
}

return attempts >= 3 ? "true" : "false";

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

3. Формирование инцидента

При третьем совпадении CEP:

1. клонирует первое подходящее исходное событие;

2. переименовывает копию в Brute force attack;

3. повышает её критичность до High;

4. подавляет исходные события на неопределённый срок.

В результате оператор видит один инцидент, а три исходные попытки сохраняются в Zabbix и доступны для анализа. Четвёртая попытка тоже может быть подавлена, пока число событий в окне остаётся не меньше трёх.

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

Примеры других сценариев

Сетевой сбой с причиной и симптомами

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

Неудачное резервное копирование с последующим успешным

Окно группируется по backup_job_id. Несколько ошибок остаются в окне, а успешное завершение задания закрывает окно и связанные неудачи. Режим Simple once не позволяет резервному правилу повторно обработать то же событие.

Флап сетевого порта

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

Автоматическое закрытие по TTL

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

Когда выбирать CEP, а когда — старые механизмы

Часто лучший результат даёт сочетание механизмов. Зависимости убирают очевидный каскад, теги задают контекст, CEP объединяет события во времени, а действия отвечают за уведомления и автоматизацию.

Ограничения Zabbix 8.0 (дорелизные версии)

Обратите внимание на пункты ниже. На момент написания и публикации этой статьи актуальной версией была 8.0.0rc1, которая является только релиз-кандидатом и не включает в себя полный заявленный функционал (пишу это на случай, если вы будете что-то тестировать).

Пока нет полноценного экспорта и импорта CEP-правил. В ZBXNEXT-10737 эта возможность как раз обсуждается.

Пока нет отдельной точки выполнения при восстановлении существующего события. В ZBXNEXT-10824 описано, что правило реагирует на появление PROBLEM-события, добавление, вытеснение и закрытие окна, но не получает отдельный вызов в момент перехода уже существующего события из OPEN в CLOSED. Это влияет на сценарии, где нужно немедленно отреагировать именно на восстановление.

Клонированные события требуют защиты от повторной обработки. Копия проходит через CEP как обычное событие. В операциях и скрипте нужно явно исключать Event is clone или проверять event.is_copied, иначе возможны повторные совпадения и циклы.

Память и размер окон нужно проектировать. Большая длительность, высокая ёмкость и слишком общий ключ группировки увеличивают число хранимых событий. Разумным шагом будет создавать отдельные окна по сервису, хосту, IP-адресу, заданию или другому стабильному тегу.

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

Вывод

Функционал, как по мне, очень классный и дает много приятных возможностей. CEP превращает обработку событий Zabbix из набора реакций на отдельные триггеры в обработку потока с памятью (ключевое слово тут «память»). Главные блоки механизма — условия отбора, временные окна, группировка, точки выполнения и операции. Простые режимы подходят для нормализации и дедупликации, группировка причины и симптомов — для каскадных отказов, а Pattern match — для сценариев, где решение зависит от нескольких событий за интервал времени.

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

Пока Zabbix 8.0 находится на дорелизных этапах, CEP лучше тестировать в непродуктивных средах.

Если вы хотите более подробно узнать об этом механизме, подписывайтесь на телеграм-канал Zabbix Recipes, где вскоре я анонсирую проведение вебинара.