Ansible Automation Platform 2.3: пробуем Event-Driven Ansible для автоматической реакции на алерты Zabbix

Red Hat выпустила Ansible Automation Platform 2.3, и главное в этом релизе - Event-Driven Ansible (EDA) переходит из технического превью в GA. Для нас это был сигнал: хватит читать документацию, пора щупать руками на реальном сценарии.

Сценарий выбрали без особых раздумий - тот, который давно висел в очереди. У нескольких клиентов на управляемой инфраструктуре одна и та же история: Zabbix видит проблему, отправляет оповещение дежурному, дежурный в нерабочее время через 15-30 минут выполняет один и тот же плейбук восстановления. Рутина, которая не требует экспертизы, но требует присутствия живого человека. Вот именно это мы и хотели убрать.

Что такое Event-Driven Ansible и чем он отличается от обычного Ansible

Обычный Ansible - это push-модель: вы решаете, что запустить, и запускаете. EDA добавляет событийно-управляемый слой: он слушает источники событий (rulebook sources), оценивает условия (rules) и при срабатывании запускает действие - в том числе ansible-playbook или job template в AWX/Controller.

Ключевые компоненты, с которыми пришлось разобраться:

• Rulebook - yaml-файл, описывающий источники событий и правила реакции на них. Это основной строительный блок EDA.
• eda-server - новый сервис в составе AAP 2.3, который хранит rulebook-ы, активации и историю срабатываний. В предыдущих версиях его не было - запускали ansible-rulebook вручную.
• ansible-rulebook - CLI, который непосредственно выполняет rulebook. Может работать и без eda-server, что удобно для разработки.
• Decision Environment - контейнерный образ с нужными коллекциями и зависимостями, аналог Execution Environment, но для EDA.

Как собрали связку с Zabbix

Zabbix умеет отправлять webhook-уведомления при срабатывании триггера. Мы пошли именно по этому пути: EDA слушает HTTP-endpoint, Zabbix дёргает его при проблеме.

В rulebook источник событий выглядит так:

sources:
  - ansible.eda.webhook:
      host: 0.0.0.0
      port: 5000

Дальше идут правила. Мы сделали несколько: для конкретных сервисов, которые умеем восстанавливать автоматически, и одно «поймать всё остальное и создать тикет».

rules:
  - name: Restart nginx on high error rate
    condition: event.payload.trigger.name == "Nginx error rate > threshold"
    action:
      run_job_template:
        name: "restart-nginx"
        organization: "Default"
        job_args:
          extra_vars:
            target_host: "{{ event.payload.host.host }}"

На стороне Zabbix - стандартный media type webhook, который отправляет JSON с информацией о триггере, хосте и severity. EDA разбирает этот JSON и проверяет условия.

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

Несколько моментов, которые стоили нам лишних часов:

Структура payload от Zabbix. Документация EDA описывает, как парсить событие, но конкретная структура JSON от Zabbix зависит от версии и конфигурации шаблона webhook. Пришлось несколько раз перебирать пути к полям (event.payload.trigger.name vs event.payload.name - в зависимости от того, как написан шаблон в Zabbix).

Decision Environment. Для работы с AWX Controller нужна коллекция ansible.controller. Стандартный образ de-supported её содержит, но если строить свой - легко пропустить. Мы полчаса дебажили ошибку активации, пока не обнаружили, что в нашем кастомном DE просто нет нужной коллекции.

Дублирование срабатываний. Zabbix может отправить несколько уведомлений для одной проблемы (при смене severity, при ре-эскалации). EDA не имеет встроенной дедупликации - если хочешь избежать параллельного запуска нескольких одинаковых плейбуков, нужно либо управлять этим в самом плейбуке, либо настраивать throttle в условии. Мы выбрали второй путь.

Что получилось

После нескольких итераций связка заработала. Алгоритм примерно такой:

1. Zabbix фиксирует проблему и отправляет webhook в EDA.
2. EDA проверяет условия rulebook-а.
3. Если условие совпало - запускается job template в Controller, который выполняет плейбук восстановления с нужным хостом в extra_vars.
4. Результат выполнения появляется в истории AWX - есть что показать на следующий день.
5. Если Zabbix прислал «problem resolved» раньше, чем plейбук закончился - ничего страшного, плейбук всё равно дойдёт до конца.

Тест на нескольких реальных инцидентах (заранее спровоцированных в тестовой среде) показал, что от момента срабатывания триггера в Zabbix до начала выполнения плейбука проходит 10-20 секунд. Это сильно быстрее любого дежурного инженера в ночное время.

Что ещё заметили про EDA 2.3

EDA eda-server в AAP 2.3 - это первый полноценный релиз, и это чувствуется. UI для управления активациями есть, но базовый. Логи активации смотреть неудобно - приходится либо через API, либо лезть в поды. Не критично, но в голове держать стоит.

Коллекция ansible.eda содержит несколько готовых источников событий: webhook, Kafka, AWS SQS, alertmanager, dynatrace. Kafka и alertmanager - это очевидные следующие кандидаты для расширения схемы, там у нас тоже есть задачи.

Документация по rulebook-ам и синтаксису условий пока неполная - часть вещей понятна только из примеров в репозитории ansible/event-driven-ansible на GitHub. Это нормально для только что вышедшего GA, но нужно иметь в виду.

Где мы сейчас

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

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