У меня есть куча «сценариев ночной смены» для обслуживания сервера. Проблема в том, что «окно действий», в котором могут выполняться эти сценарии, всегда разное. Иногда ничего не происходит в течение нескольких минут и часов, иногда сервер обрабатывает некоторые данные всю ночь. Скрипты - это не только (но в основном) скрипты БД.
Один разработчик пришел с идеей реализовать демона. Этот демон должен проверять условия сервера, и если будет найдено достаточно свободных ресурсов, будут запущены некоторые скрипты.
Я считаю эту идею интересной (чтобы не сказать соблазнительной ;-)), но не буду изобретать велосипед. Есть ли проверенные закономерности? Может быть, какие-нибудь плагины Shinken или Nagios?
В мире nagios вы можете связывать задачи, используя обработчики событий по услугам.
Обработчики событий на самом деле вторая команда выполняется после первой служебной команды, всегда, (если активировано в глобальной конфигурации и для этой услуги). Основное использование обработчика событий состоит из его запуска с указанием состояния службы и результатов выполнения команды. Затем сценарий обработчика событий анализирует состояние службы (все ли мы в порядке / ПРЕДУПРЕЖДЕНИЕ / КРИТИЧЕСКОЕ? Это было первое, когда проверка отправила нам это состояние? Жесткое или мягкое состояние и т. Д.) И решает в конечном итоге запустить команду. Предыдущая ссылка на документацию показывает базовый сценарий bash, выполняющий это (будьте осторожны, обработчик событий всегда запускается, даже после успешного результата).
Таким образом, вы можете добавить обработчик событий в службу средней нагрузки, и этот обработчик событий может запускать задачи обслуживания, потребляющие ваш процессор, когда состояние службы в порядке. Или он может просто установить флаг где-нибудь в вашей файловой системе, и ваша задача cron будет проверять этот флаг перед запуском.
Теперь вам может потребоваться объединить результаты нескольких сервисов, прежде чем решить, действительно ли система готова к запуску задач, по нескольким причинам:
Некоторые проверки вроде check_cluster может помочь вам объединить результаты нескольких служб и получить службу в состоянии ОК, если 3 службы из 5 находятся в состоянии ОК (например). Затем вы должны установить обработчик событий для службы с помощью check_cluster.
Управление "Я опоздал" статус сложнее. Лучшее место для этого - код обработчика событий (игнорируйте критическое состояние или состояние предупреждения, если вы опаздываете).
Вы также могли бы периоды времени ограничения (пример: задачи обслуживания должны выполняться только в пятницу вечером). У вас есть несколько рецептов. IMHO, лучший вариант - установить флаг только с помощью обработчика событий и установить периоды времени с помощью планировщика задач обслуживания (crontab). Nagios предоставляет периоды времени которые можно было бы подключить к вашей службе, но даже в последних выпусках Nagios были серьезные ошибки со службами, которые не были запланированы для работы 7/7 24/24, ошибки, которые подталкивали выполнение следующей службы за пределами периода времени, а затем подталкивали ее через неделю ( почему 1 неделя?) и больше никогда не запускать сервис). Cron или любой внешний планировщик сделает более качественные и надежные планировщики обслуживания (я не тестировал планировщик Shinken, возможно, он действительно поддерживает официальную расширенные периоды времени)