Шина событий

Шина событий — pub/sub-канал на мастере, через который проходит вся «телеметрия» Salt. Каждое событие устроено одинаково: тег — строка с иерархией через / (например, salt/job/20260730123456789/ret/web-01) — и полезная нагрузка, словарь данных. События порождает всё: публикация job и возвраты миньонов, аутентификация и принятие ключей, старт миньонов, срабатывания beacons, ваши собственные event.send. Локально шина доступна процессам мастера через IPC-сокет, между машинами события ходят по ZeroMQ-транспорту. Шина — это одновременно главный инструмент наблюдения за живой системой и фундамент, на котором построены reactor и оркестрация: прежде чем автоматизировать реакции, нужно уметь читать этот поток.

Как это работает

Смотреть шину вживую — одна команда на мастере: salt-run state.event pretty=True; она печатает каждое событие с тегом и отформатированным JSON данных. Запустите её в соседнем терминале и выполните salt '*' test.ping — вы увидите весь цикл: событие публикации job с тегом salt/job/<jid>/new (в данных — таргет, функция, аргументы), затем по событию salt/job/<jid>/ret/<minion> на каждый возврат. Другие характерные теги: salt/auth — обмен ключами, salt/minion/<id>/start — миньон поднялся, salt/beacon/<id>/... — сработал beacon. Собственные события шлются с миньона командой salt-call event.send 'myorg/deploy/done' '{"version": "1.2.3"}' — тег свободный, данные — любой JSON-словарь. Внешним системам поток отдаёт salt-api: HTTP-стрим событий, на который можно подписаться из скрипта или дашборда, не заходя на мастер.

Когда применять

Первый повод открыть шину — отладка: job «завис», таргетинг «не сработал», beacon «молчит» — salt-run state.event pretty=True показывает, что происходит на самом деле: дошла ли публикация, вернулся ли миньон, с каким содержимым пришло событие. Это быстрее и точнее, чем раскапывать логи. Второй — интеграции: CI шлёт событие о деплое, скрипт мониторинга слушает возвраты, внешняя система получает поток через salt-api. Третий — как контракт для reactor: прежде чем писать реакцию, смотрят реальный тег и структуру данных события, на которое собираются реагировать, — документация не всегда поспевает за конкретной версией, а шина не врёт.

Типичные ошибки

Главное заблуждение — считать шину надёжной очередью сообщений. Это pub/sub без персистентности: не было подписчика в момент публикации — событие потеряно, механизма повторной доставки и replay нет. Для истории job существуют returner'ы и job cache, для гарантированной доставки — внешние брокеры; шина же — про «сейчас». Вторая ошибка — парсить вывод CLI-команд вместо подписки на события: хрупко и гонково, тогда как шина отдаёт структурированные данные. Третья — секреты в полезной нагрузке событий: поток видят все, у кого есть доступ к мастеру или к salt-api-стриму, поэтому пароли и токены в event.send класть нельзя. И следите за тегами своих событий: без согласованного префикса (myorg/...) шина быстро превращается в свалку.

Связанные понятия

• События и Reactor
• Beacons
• Reactor
• Runners и salt-run
• salt-api (REST)