Мониторинг Salt

Salt управляет всей инфраструктурой — значит, сам он должен быть под наблюдением не хуже продакшен-сервисов. Мониторинг Salt складывается из трёх вопросов: жив ли контур управления (мастер работает, миньоны на связи), что происходит с заданиями (успехи, падения states, время выполнения) и что происходит на самих узлах. Для всех трёх у Salt есть встроенные механизмы: шина событий — единый поток всего, что происходит в системе; returners — доставка результатов заданий во внешние системы; beacons — датчики на миньонах, превращающие локальные события ОС в события шины. Из этих кирпичей собирается и наблюдаемость, и — вместе с reactor — самовосстановление.

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

Всё, что делает Salt, порождает события на шине мастера: подключения миньонов, приём ключей, публикация заданий, каждый возврат результата. Смотреть поток вживую: salt-run state.event pretty=True — это первый инструмент отладки «почему ничего не происходит». Опция event_return в конфиге мастера направляет копию событий в выбранный returner — так события становятся историей во внешнем хранилище. Returners решают и задачу результатов: salt '*' state.apply --return <имя_returner'а> отправляет результат задания не только на мастер, но и во внешнюю систему — в каталоге returner'ов десятки модулей под разные базы, мессенджеры и системы алертинга. Beacons работают с другой стороны: настроенный на миньоне beacon (например, на использование памяти, статус сервиса или изменение файла через inotify) периодически проверяет условие и публикует событие на шину. Связка beacon → reactor замыкает цикл: упал сервис — событие — reactor запускает state, который его поднимает. Живость парка проверяется runner'ом salt-run manage.status (списки up/down по данным последних контактов).

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

Минимальный уровень для любого продакшена: системный мониторинг процессов salt-master/salt-minion и портов 4505/4506 плюс регулярная проверка salt-run manage.down — миньоны имеют свойство тихо отваливаться после сетевых работ. Следующий уровень — история заданий во внешней системе через returner или event_return: без неё вопрос «что сломало ночной highstate» превращается в раскопки job cache на мастере. Beacons включайте точечно — для условий, которые важно ловить именно на узле и быстро: заполнение диска, падение критичного сервиса, изменение защищаемого файла. Полноценный APM для Salt не обязателен, но связка «события в хранилище + алерты на падения states + manage.down по расписанию» закрывает большинство реальных инцидентов.

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

Первая — мониторить только процесс мастера: демон жив, а воркеры перегружены, и миньоны ловят таймауты; следите за симптомами (время test.ping, доля неответивших), а не только за наличием процесса. Вторая — event_return во внешнюю систему без оценки объёма: шина большого парка генерирует плотный поток, и медленный returner тормозит самого мастера — фильтруйте, что писать. Третья — beacons с коротким интервалом и тяжёлой проверкой: датчик сам создаёт нагрузку, которую призван ловить. Четвёртая — доверять manage.status как истине в последней инстанции: он опирается на последние контакты миньонов, и «up» не гарантирует, что миньон исполнит задание; контрольный test.ping надёжнее. Пятая — отсутствие алертов на непринятые ключи: новый узел «не работает», хотя просто ждёт salt-key -a.

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

• Шина событий
• Beacons
• Reactor
• Тюнинг производительности
• Runners и salt-run