Доступен (http://lists.gnu.org/archive/html/monit-announce/2011-09/msg...) релиз Monit 5.3 (http://mmonit.com/monit/), легковесного пакета для организации мониторинга серверов. Monit устанавливается на конечные серверы и обеспечивает возможность отправки уведомлений в случае обнаружения проблем, таких как нарушение доступности хоста, нехватка места на диске, изменение контрольной суммы для файла и т.п. Кроме того, Monit может автономно выполнять определенное действие в качестве реакции на заданные события (например, перезапустить упавший процесс или принять какие-то меры в случае нехватки памяти и большой нагрузки на CPU).
Для просмотра состояния и внешнего управления в Monit встроен небольшой http-сервер (скриншоты возможных отчетов можно посмотреть здесь (http://mmonit.com/monit/screenshots/)). Программа написана на языке Си и может работать с минимальным числом внешних зависимостей. Дополнительно развивается web-интерфейс M/Monit (http://mmonit.com/) для обеспечения це...URL: http://lists.gnu.org/archive/html/monit-announce/2011-09/msg...
Новость: http://www.opennet.me/opennews/art.shtml?num=31747
check program myscript with path "/usr/local/bin/myscript.sh"
if status != 0 then alert
УРА! Давно ждал!
Замечательная штука!
Этакий швейцарский костыль.
Под высокой нагрузкой, когда демоны нет нет да валятся, позволяет жить!
>Под высокой нагрузкой, когда демоны нет нет да валятся, позволяет жить!Давно уже существуют всякие SMF, upstart, systemd.
> Давно уже существуют всякие SMF, upstart, systemd.Когда это они научились показывать статус в веб, отсылать email (а это шлюз для SMS) и ещё over 9000 фич?
>Когда это они научились показывать статус в вебСвязь между задачами "показывать статус в веб" и "перезапускать демона при падении" очень слабая. Потому что первая из них должна решаться специализированным софтом, а вторая непосредственно входит в задачи системы инициализации. И когда задачи init пытаются взвалить на левую софтину, это уже костыли.
Что касается отсылки уведомлений (и любых других действий, вплоть до включения звоночка над кроватью админа) по событию, то их не умеет только ленивый.
>Когда это они научились показывать статус в веб, отсылать email (а это шлюз для SMS) и ещё over 9000 фич?Вообще-то, изначально речь шла всего лишь об автоматическом перезапуске демонов
>Под высокой нагрузкой, когда демоны нет нет да валятся, позволяет жить!
И решать эту задачу при помощи "показывалки статуса в вебе" немного кривовато, вы не находите?
Показывалка статуса - это еще одна полезная возможность, автоматический подъем демона делается не через неё, а так:
check process xxx with
pidfile /var/run/xxx.pid
start program = "/etc/init.d/xxx restart" with timeout 10 seconds
stop program = "/etc/init.d/xxx stop" with timeout 5 seconds
С новым 'crontab' синтаксисом стало еще проще делать проверку для проблемного приложения хоть каждую секунду.
>Показывалка статуса - это еще одна полезная возможностьА такой полезной возможности, как проигрывание музыки, там нет?
Когда в одну программу запихивается куча слабо связанных между собой функций - это уже попахивает виндой. И уж тем более - когда отдельные функции влезают в круг задач других программ (в частности, системы инициализации).>С новым 'crontab' синтаксисом стало еще проще делать проверку для проблемного приложения хоть каждую секунду.
О ужс, там синхронный опрос? А вот системы инициализации, как правило используют асинхронные механизмы (типа уведомлений от cgroups в systemd), что гораздо приятнее в плане как скорости реакции, так и производительности (особенно если нужно мониторить много приложений).
Для системы мониторинга проигрывание музыки не требуется, а вот наглядное отображение состояния вполне в тему.
cgroups есть где-то кроме Linux? Оно позволяет, скажем, следующие конструкции?if failed host 192.168.1.100 port 8080 protocol http
and request '/testing' hostheader 'example.com'
with checksum8f7f419955cefa0b33a2ba316cba3659
with timeout 10 seconds
then restartif failed host cave.persia.ir port 4040
send "Open, Sesame!\r\n"
expect "Please enter the cave\r\n"
send "Shut, Sesame!\r\n"
expect "See you later [A-Za-z ]+\r\n"
then restart
>Для системы мониторинга проигрывание музыки не требуетсяПочему? Вдруг админу во время наглядного просмотра состояния станет грустно?
>cgroups есть где-то кроме Linux?
Breaking news: асинхронные механизмы уведомления родителя о смерти потомков есть не только в Linux. Так как init - родитель процессов служб, он и должен их обрабатывать. В отличие от "внешней" системы мониторинга, которая вынуждена ковылять на костылях.
>Оно позволяет, скажем, следующие конструкции?
Вот до чего доводит порочная логика. Если не отвечает порт _удаленного_ хоста, перезапуском службы должен заниматься сервер мониторинга. Может, на него еще и fencing в кластерах взвалить?
Со своей стороны могу повторить вопрос: эта чудесная система мониторинга может поддерживать сокет открытым на время перезапуска службы, так чтобы не потерять ни одного запроса?
Я вовсе не спорю с тем, что системы мониторинга нужны и полезны. Мне просто не нравится, что они лезут в задачи системы инициализации, не располагая соответствующими возможностями, что неизбежно ведет к кривым костылям.Что же касается удаленного мониторинга служб - уже давно существуют кластерные менеджеры ресурсов (по сути, это распределенные системы инициализации), которые решают эту задачу куда более прямыми методами. И, соответственно, предоставляют гораздо больше возможностей (например, если служба упала на одном хосте, ее можно запустить заново уже на другом, автоматически перенастроив фронтенд).
Bo первых все кроме SMF существует относительно недавно. Во вторых предлагаете из-за одного проблемного сервиса менять на сервере столь ответственную штуку как init ?
> Bo первых все кроме SMF существует относительно недавно.То-то я смотрю, уже год как шестой RHEL с upstart вышел.
> Во вторых предлагаете из-за одного проблемного сервиса менять на сервере столь ответственную штуку как init ?
Я предлагаю решать проблему, а не завешивать ее тряпочкой. Начнем с того, что демон вообще не должен падать.
на *BSD этого нет
> на *BSD этого нетНу так никто и не предлагает их использовать на критических серверах. Большому плаванью - большие корабли.
> Замечательная штука!
> Этакий швейцарский костыль.
> Под высокой нагрузкой, когда демоны нет нет да валятся, позволяет жить!Скажите, а оно может, как systemd, на время перезапуска службы поддерживать открытым сокет и накапливать поступающие запросы (чтобы после запуска демон смог их обработать)?
если демоны валятся, и чудо-поделие отправляет смски, то это похоже, как вместо похода к доктору с аппендицитом, поциент постит свои боли в твиторе
> если демоны валятся, и чудо-поделие отправляет смски, то это похоже, как вместо похода к доктору с аппендицитом, поциент постит свои боли в твитореЧто вы предлагаете как альтернативу? Систему искусственного интеллекта, которая при падении демона разбирается в причинах, тюнит конфиг, оптимизирует рабочие данные, банит атакующих кульхацкеров и т.д., а админу при этом ничего не говорит?
Я бы тоже такую хотел, да вот только никто так и не написал ничего похожего... =(
> Что вы предлагаете как альтернативу?Да ничего он не предлагает, это просто очередной перфекционист из числа админов локалхоста.
>/var/run/mysqld.pidКоллеги, это он так мониторит "процессы"??? по pid-у? Так не пойдет.
Процесс может вылететь так, что в pid-файле ничего не поменяется. У меня даже есть пример тому - freeradius.
он прверяет существует ли процесс который имеет такой же pid как в указанном файле.
А что мешает в интервале между падением процесса и операцией проверки запуститься другому, совершенно левому процессу с тем же идентификатором?
Вы бы, сударь, хотя бы удосужились посмотреть, как он это в действительности делает. А не судить по тому, как абрамович напел.Там куча способов слежения. И по доступности порта и остальное прочее. А по пиду уже ответили.