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