Мониторинг Salt

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

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

Все действия Salt порождают события на шине мастера: подключения миньонов, приём ключей, публикация заданий, возвраты результатов. Для просмотра потока событий в реальном времени используйте команду salt-run state.event pretty=True. Это первый инструмент для отладки проблем с выполнением заданий. Опция event_return в конфиге мастера направляет копию событий в выбранный returner, что позволяет сохранять историю событий во внешнем хранилище. Returners также решают задачу отправки результатов заданий: команда salt '*' state.apply --return <имя_returner'а> отправляет результаты не только на мастер, но и во внешнюю систему. В каталоге returner'ов есть десятки модулей для различных баз данных, мессенджеров и систем алертинга. Beacons на миньонах периодически проверяют условия (например, использование памяти, статус сервиса или изменения файлов через inotify) и публикуют события на шину. Связка beacon → reactor обеспечивает автоматическое восстановление: если сервис упал, событие активирует reactor, который запускает state для восстановления сервиса. Живость парка можно проверить командой 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