Комментарии 10
Очень странный подход, понимаю что, because i can, но не лучше ли использовать готовые инструменты?
Завтра понадобятся отчеты, графики для наглядности или цвообще передать поддержку другому человеку и простое вроде бы решение превратится в дополнительные проблемы и потерю времени.
Завтра понадобятся отчеты, графики для наглядности или цвообще передать поддержку другому человеку и простое вроде бы решение превратится в дополнительные проблемы и потерю времени.
Конечно нет необходимости изобретать очередной велосипед в стиле nagios. Задачи, кроме тривиального пинга могут быть самые разнообразные, например выполнить последовательность действий через ssh на удаленном хосте или исполнить sql-скрипт. Я уж не говорю о периодическом опросе каких-нибудь веб-ресурсов с целью получения и обработки статистических данных.
Не понятно ровным счетом ничего. Какая конкретно задача решалась? Для кого предназначен мониторинг? Для админов/девелоперов? Или для того, чтобы в каком-то виде показывать данные мониторинга пользователями?
ИМХО, касательно систем мониторинга, гораздо больший интерес представляет не конкретный фрагмент кода, а вся картина целиком.
Каюсь, код на гитхабе не смотрел, но мне кажется, это должно быть указано в статье.
1. Как происходит обнаружение хостов и сервера мониторинга?
2. Какие механизмы используются для транспорта сообщений между сервером мониторинга и хостами?
3. Как участники (сервер и хосты) обрабатывают потерю связи друг с другом?
4. Откуда вообще (конкретно в вашем случае) берется набор тасков-проверок?
5. Где, в каком виде хранятся результаты проверок? Насколько детальную информацию можно оттуда получать.
6. Есть ли (конкретно в вашем случае) возможность разбивки проверок по разным группам/ролям?
Вот было бы интереснее, если бы в статье описывался ваш опыт использования своих кастомных велосипедов (в хорошем смысле слова).
Ну и, опять же, было бы интересно прочитать про это все в сравнении с другими (настоящими) системами мониторинга.
PS: Мне кажется, вы-таки не видели sensuapp.org/
ИМХО, касательно систем мониторинга, гораздо больший интерес представляет не конкретный фрагмент кода, а вся картина целиком.
Каюсь, код на гитхабе не смотрел, но мне кажется, это должно быть указано в статье.
1. Как происходит обнаружение хостов и сервера мониторинга?
2. Какие механизмы используются для транспорта сообщений между сервером мониторинга и хостами?
3. Как участники (сервер и хосты) обрабатывают потерю связи друг с другом?
4. Откуда вообще (конкретно в вашем случае) берется набор тасков-проверок?
5. Где, в каком виде хранятся результаты проверок? Насколько детальную информацию можно оттуда получать.
6. Есть ли (конкретно в вашем случае) возможность разбивки проверок по разным группам/ролям?
Вот было бы интереснее, если бы в статье описывался ваш опыт использования своих кастомных велосипедов (в хорошем смысле слова).
Ну и, опять же, было бы интересно прочитать про это все в сравнении с другими (настоящими) системами мониторинга.
PS: Мне кажется, вы-таки не видели sensuapp.org/
Статья интересная и задача актуальная. Я сам ищу решение: готовое приложение, которое можно было бы легко разместить на нескольких серверах (на случай, если сервер с которого мониторим, сам выходит из строя).
Запускать тысячу потоков плохо. Но если «свои дела» при работе с каким-то сервером занимают продолжительное время? А что если запускать ограниченное количество потоков (не на каждый севрер, а скажем 10, или процент от общего количества серверов мониторинга), и каждый из потоков, освободившись берет очередное необработанное задание и из очереди?
Запускать тысячу потоков плохо. Но если «свои дела» при работе с каким-то сервером занимают продолжительное время? А что если запускать ограниченное количество потоков (не на каждый севрер, а скажем 10, или процент от общего количества серверов мониторинга), и каждый из потоков, освободившись берет очередное необработанное задание и из очереди?
Так и делается обычно. Таски, поступающие в очередь, разгребаются не одним потоком, а пулом воркеров. Если отпилить очередь от самого сервера (например, использовать rabbitmq), то вопрос отказоустойчивости решается достаточно тривиально — достаточно запустить насколько «разгребаторов» на разных машинах. Если интересует что-то готовое — могу повториться и посоветовать sensu (http://sensuapp.org). Правда, назвать его готовым решением тяжеловато. Это скорее фреймворк для построения своей собственной системы мониторинга. Работает оно приблизительно так, как я и описал — все сервисы, которые надо мониторить, подписываются через rabbitmq на определенные проверки. Отдельные инстансы самого сервера (их может быть несколько) принимают эти подписки и время от времени запрашивают у сервисов результаты проверок.
Проблем нет. В опубликованном в исходниках юнит-тесте в качестве пула потоков используется cachedThreadPool, что означает что максимальное количество потоков будет равно (но может быть и меньше) количеству серверов. Если использовать fixedThreadPool, то количество рабочих потоков можно сократить (например 1 поток на 10 серверов), но тогда есть риск что «медленные» сервера будут тормозить весь процесс обработки. Но и эту проблему можно решить, если выстроить приоритеты для «медленных» и «быстрых» серверов в «револьвере».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мониторинг серверов через очередь заданий на JAVA