Event-Driven Ansible + Zabbix: автоматическая реакция на инциденты в продакшне

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

Если совсем коротко: EDA в 2.4 работает. Но архитектура интеграции с Zabbix требует аккуратности в нескольких местах, которые в документации не очевидны.

Как устроена схема в целом

Общая цепочка несложная: Zabbix фиксирует проблему - отправляет webhook на eda-server - EDA применяет rulebook и запускает нужный job template в Ansible Controller - плейбук восстанавливает сервис или уведомляет on-call.

Три точки в этой цепочке, где всё может пойти не так:

Первое - webhook со стороны Zabbix. Zabbix отправляет webhook-уведомление из action-а, и важно правильно сформировать payload. EDA ждёт JSON определённой структуры, а Zabbix по умолчанию шлёт то, что сконфигурировано в медиатипе. Если структура не совпадает с тем, что проверяет rulebook, условие просто не срабатывает - тихо и без ошибки в логах EDA. Отладка заняла время.

Второе - структура rulebook-а. Конкретно - throttle и условия группировки. Без throttle при каскадном падении (один хост роняет несколько сервисов) EDA параллельно запускает несколько recovery-плейбуков на один хост, что само по себе может создать проблему. С throttle надо чётко понимать, по каким атрибутам группировать - по хосту, по типу триггера, или по обоим.

Третье - разделение триггеров на «автоматизируемые» и «нет». Это организационный вопрос, но технически решается через кастомные теги в Zabbix. Не каждый триггер должен запускать автоматику. Логика такая: тег eda_action с нужным значением есть - EDA реагирует, нет - алерт уходит дежурному как обычно.

Что из сценариев покрываем

Три класса плейбуков, которые реально используем:

Перезапуск сервиса. Самый простой случай: systemd-юнит упал, Zabbix это видит, EDA запускает systemctl restart, проверяет статус через несколько секунд. Если сервис поднялся - закрывает инцидент через Zabbix API (есть и такой плейбук). Если нет - эскалирует на дежурного.

Освобождение диска под логи. Один из реальных сценариев, с которого начинали: диск под /var/log заполняется ротированными, но не почищенными логами. Триггер по порогу - EDA запускает очистку через find с нужными параметрами. Здесь важен дополнительный чек: смотрим, что именно занимает место перед тем как что-то удалять, чтобы не снести что-то не то.

Нотификация on-call с контекстом. Для триггеров, которые не предполагают автоматического восстановления, но требуют быстрой реакции, EDA играет роль enrichment-слоя: собирает базовый контекст (последние строки лога, статус смежных сервисов, загрузка CPU) и отправляет дежурному в Telegram уже с преварительной диагностикой. Человек подключается с пониманием ситуации, а не с нуля.

Подводный камень с idempotency

Это место нас удивило больше всего. Recovery-плейбуки должны быть идемпотентны - звучит очевидно. Но конкретная ловушка: Zabbix может прислать несколько webhook-ов за короткое время (retry при недоступности eda-server, или если триггер несколько раз переключился), и плейбук запускается дважды. Если плейбук просто делает systemctl restart - ничего страшного. Если внутри есть логика с проверкой файлов, изменением конфигурации или работой с базой - надо явно обрабатывать ситуацию «плейбук уже отработал». Throttle в rulebook-е частично помогает, но не покрывает все кейсы.

Мониторинг самого EDA

Отдельный момент, про который не думаешь заранее: EDA сам должен быть под мониторингом. Если eda-server упал или активация деактивировалась - Zabbix продолжает слать webhook-и в никуда, и никто об этом не знает. В 2.4 healthcheck активаций есть, но он внутренний. Мы добавили внешний чек: Zabbix каждые несколько минут проверяет endpoint eda-server и статус активаций через API. Звучит немного рекурсивно - мониторинг мониторинга - но иначе схема не замкнута.

Где сейчас

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

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

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

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