Beacons

Beacons — «органы чувств» миньона: фоновые наблюдатели, которые следят за вещами вне Salt — файлами, сервисами, нагрузкой, диском, сетевыми настройками — и превращают замеченные изменения в события на шине мастера. Обычный миньон пассивен между командами; beacon делает его источником сигналов: упал nginx — на мастер улетает событие; кто-то поправил /etc/passwd — событие; диск заполнен на 90% — событие. Настраиваются beacons декларативно — в конфиге миньона или, что удобнее для массового управления, через pillar. Сами по себе beacons ничего не чинят и никого не оповещают — они только публикуют факты; реагирует на них reactor на мастере, и в паре они образуют контур «датчик → реакция».

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

Конфигурация — словарь beacons в /etc/salt/minion (или в pillar, что позволяет раскатывать наблюдателей стандартным механизмом данных):

beacons:
  service:
    - services:
        nginx: {}
    - interval: 10
  diskusage:
    - /: 90%

Процесс миньона опрашивает каждый beacon со своим интервалом (interval, в секундах) внутри основного цикла. При срабатывании миньон публикует событие с тегом вида salt/beacon/<minion_id>/<beacon>/... и данными о том, что случилось; поток виден на мастере через salt-run state.event pretty=True. Модулей-наблюдателей много: inotify (изменения файлов, требует установленной библиотеки на миньоне), service, diskusage, memusage, load, network_settings, ps и другие — полный список в справочнике beacon-модулей. Управлять можно и на лету, без правки конфигов: salt '*' beacons.add, beacons.list, beacons.disable. Отдельная важная опция — disable_during_state_run: True: она глушит beacon на время применения состояний, чтобы не ловить изменения, которые вносит сам Salt.

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

Основной сценарий — self-healing в связке с reactor: beacon service замечает умерший процесс, reactor применяет состояние, поднимающее его обратно; время реакции — секунды, без участия человека. Второй — контроль дрейфа конфигурации: inotify на критичных файлах (/etc/ssh/sshd_config, sudoers) даёт мгновенный сигнал о ручных правках, который можно логировать или сразу откатывать highstate'ом. Третий — пороговые события: diskusage и load как триггеры для чистки или уведомлений. Важно честно понимать границу: beacons — это триггеры для автоматики, а не система мониторинга; метрики, графики, алертинг с дедупликацией — задача Prometheus/Zabbix, и заменять их beacons не стоит.

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

Первая — слишком агрессивные интервалы: beacon с interval: 1 на сотнях миньонов создаёт постоянный шум на шине и фоновую нагрузку; выбирайте интервал от реального времени реакции, которое вам нужно. Вторая — забытый disable_during_state_run: Salt правит конфиг, inotify это ловит, reactor запускает состояние, оно снова правит файл — получается цикл, который находят по загадочно «дёргающемуся» мастеру. Третья — зависимости: тот же inotify не заработает без соответствующей библиотеки Python на миньоне, а ошибка будет видна только в логе миньона. Четвёртая — реакция на каждое событие без агрегации: мигающий сервис (flapping) породит шквал событий и шквал реакций; в reactor-логике нужна защита от повторов.

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

• Шина событий
• Reactor
• События и Reactor
• Конфигурация minion
• Мониторинг Salt