Страница 1 из 1

Децентрализованный мониторинг

Добавлено: 05 окт 2010 00:31
Dizelsky
Шалом, котики.
Собственно, есть N серверов на линуксах, где N>1. Надо эту группу мониторить - место, cpu, процессы и и прочие глупости. Бида классических систем мониторинга - центральный сервер. Если он мрет - об этом вряд ли можно узнать оперативно. Как вариант - настроить костылик для мониторинга центрального сервера. Но это некрасиво, неэффективно и так далее...
Что хочу сделать - децентрализованная кластерная система мониторинга. Все сервера равноправны и все следят друг за другом. В общем отказоустойчивая пепяка. В алгоритмах вопросов нет, дело на пол часа. Проблема в транспорте.
Есть ли у кого наработки/опыт/идеи по передаче произвольных строк между серверами/процессами?

Напрашивается XMPP, т.к. админу в таком случае удобно получать сообщения, но как в таком случае посадить несколько клиентов на один аккаунт (регать для каждого новый акк - моветон).
Целый web-сервер на такие мелочи отдавать - жаба давит, да и несекурно это.
Какие еще протоколы можно тут присунуть?

ЗЫ: Предвижу зоопарк из всяких солярисов, хпуксов и прочих бздей, так что ищу наиболее универсальный метод.

Re: Децентрализованный мониторинг

Добавлено: 05 окт 2010 00:48
michael
ganglia (http://ganglia.sourceforge.net/)
Хосты собирают и передают инфу как угодно. Можно сделать и чтоб каждый знал о каждом. Инфа снимается в виде XML простым соединением через telnet к заданному порту. Есть и всякие обработчики, но с ними не возился, не знаю.

Re: Децентрализованный мониторинг

Добавлено: 05 окт 2010 01:31
Dizelsky
ganglia, да, но не то что надо.

Как я желаю видеть это на практике - Есть некое облако уже работающих серверов, вот появился новый и мне надо его быстро включить в мониторинг. Я копирую на сервер скрипт (! именно скрипт, ибо, как показывает практика, это самый удобопортируемый вариант), запускаю его всего с 2мя параметрами - пароль облака и ip одного из элементов облака. Всё остальное вполне может пройти на автомате - импорт конфигов, добавление в облако - всё это задачи вполне тривиальные. Дальше они смотрят друг за другом, оповещают о проблемах админа и обмениваются инфой о состоянии друг друга (для истории).
Нужно - безопасный и быстрый транспорт + прямые руки.

с ganglia картина будет далека от описанной...

Re: Децентрализованный мониторинг

Добавлено: 05 окт 2010 12:59
hatred
Dizelsky писал(а):Напрашивается XMPP, т.к. админу в таком случае удобно получать сообщения, но как в таком случае посадить несколько клиентов на один аккаунт (регать для каждого новый акк - моветон).
Целый web-сервер на такие мелочи отдавать - жаба давит, да и несекурно это.
Какие еще протоколы можно тут присунуть?
Есть у жабера такая чудная прелесть как RESOURCE string, которая делает аккаунт вида:
login@jabber.server/RESOURCE, то что всякие укуренные клиенты типа Google Talk пихают туда рандомную ахинею, не отменяет её функциональности. С разные RESOURCE стрингами позволяется несколько подключений от одного аккаунта... ну или как у тебя сервер настроент (к примеру, jabber.ru такое позволяет). Более того, если, клиент может запросить переслать ему сообщения, которые были адресованы другим RESOURCE и тем самым посмотреть что там творилось, пока ты ехал на работу (было полезно - дома жабер забывал выключить). Ну и... когда придет сообщение, будет в заголовке видно - от кого. А отсылалка sendxmpp как-то так, консольная. а скрипты для локальных проверок можно своровать у Nagios, благо это простые консольные программки. Всё это слепить посредством bash-script и rsync и должно быть вселенское счастие. Ну и да, про почту не забываем, тоже транспорт :-D

Re: Децентрализованный мониторинг

Добавлено: 06 окт 2010 05:52
hex
Dizelsky писал(а):Шалом, котики.
/me запасся попкорном в ожидании очередного велосипеда на подводных крыльях.

Что мониторить собираешься, пинг? Если сервак пингуется - это значит только то, что на нём жив стек TCP/IP. Иногда это единственное, что остается в живых. Или вообще другая машина себе этот IP захавала.

Сервисов, которые твои серваки будут пинговать со всех материков планеты за смешные деньги - вагон и маленькая тележка.

Вот если тебе надо ещё и пачку сервисов проверять - всё становится забавнее. Во первых, одним запуском скрипта для подключения не отделаешься. Во вторых, тебе понадобится держать распределенную базу данных. В третьих, серверам придётся проводить регулярную перекличку и распределять между собой задания на проверку/рассылку. В четвертых, решить проблему сплита на два (и более) облака. В пятых, решить проблему безопасности. Потому как поимевший любой из серверов автоматом имеет всю сеть. Дальше пункты придумывай сам )

Я свои серваки держу под контролем такой связкой: nagios на одной машине и cfengine на другой. Нагиос сообщает о проблемах, cfengine кофигурит серваки и сообщает о проблемах с nagios (при этом автоматом пытается его перезапустить). Да, разумеется nagios одним глазом следит за cfengine. И есть ещё сторонний nagios, который приглядывает за моими cfengine и nagios. Ещё есть машинка с cacti, но она так, для отслеживания здоровья пациентов.

Кстати, сервер под контроль cfengine добавляется именно копированием и запуском одного скрипта. Думаю, что при желании можно заставить cfengine регистрировать новые сервера на nagios, но ну его нафиг автоматизировать задачу, которая у меня раз в полгода всплывает )

Re: Децентрализованный мониторинг

Добавлено: 06 окт 2010 09:21
Dizelsky
hex писал(а):запасся попкорном в ожидании очередного велосипеда на подводных крыльях
как верно подмечено :)
hatred писал(а):чудная прелесть как RESOURCE string
оооо!!!!

на этом концерт окончен
/me снова покрывается на N лет

Re: Децентрализованный мониторинг

Добавлено: 07 окт 2010 01:14
hatred
гавнюк ты.

hex: у меня работало почти так же.

Re: Децентрализованный мониторинг

Добавлено: 12 окт 2010 00:47
Dizelsky
hatred писал(а):гавнюк ты.
еще какой... :)

"чудная прелесть как RESOURCE string" редко где реализована через руки, jabber как транспорт отходит на второй план.
hex писал(а):Вот если тебе надо ещё и пачку сервисов проверять
угу, парочку сервисов, парочку интерфейсов, наполняемость БД, наполняемость и ротацию файлов, присутствие неизвестных mac в бродкасте, аномалии по трафику и прочие глупости, что в голову придут... Отсюда же и диференциация сообщений по приоритетам, разные получатели. Nagios поможет, но он уродско конфигурируется и туго кластеризуется.

пока что больше вопросов чем ответов... Думаю как лучше сделать

Re: Децентрализованный мониторинг

Добавлено: 12 окт 2010 01:08
hex
Dizelsky писал(а):Nagios поможет, но он уродско конфигурируется и туго кластеризуется.
Глянь на http://www.icinga.org/, заодно нам расскажешь, чем он от Nagios отличается. Говорят, конфигурируется проще.

Re: Децентрализованный мониторинг

Добавлено: 12 окт 2010 02:12
hatred
я думал ты хоть свой jabber сервер имеешь... кстати jabber.ru вроде как нормально строки поддерживает. Кстати, а как сервер будет мониторить, если он от сети отвалился? :)

Re: Децентрализованный мониторинг

Добавлено: 13 окт 2010 10:09
Dizelsky
hatred писал(а):как сервер будет мониторить, если он от сети отвалился
Если "он" это сам объект монторинга, то за него это должны сделать соседи из его же cloud`а
Если "он" это jabber сервер, то это решается:
a) собственным сервером. То есть один сервер-объект - один jabber сервер == накладно, громоздко и некрасиво
b) уходом на децентрализованный транспорт, что в контексте децентрализованного мониторинга на порядок лучше.

Re: Децентрализованный мониторинг

Добавлено: 13 окт 2010 10:29
Dizelsky
hex писал(а):
Dizelsky писал(а):Nagios поможет, но он уродско конфигурируется и туго кластеризуется.
Глянь на http://www.icinga.org/, заодно нам расскажешь, чем он от Nagios отличается. Говорят, конфигурируется проще.
Может где-то и проще, но особой разницы с нагиосом не увидел.
Метод "Redundant and Failover Network Monitoring" у них это вообще ппц.
Redundant - две копии этого монстра седят друг за другом. Один из них мастер. У слейва отключают notification пока мастер жив. Никакого обмена конфигами, то есть при появлении новой железки её придется заводить дважды
Failover - Те же яйца, только слейв в это время выключен и при включении он уже становится мастером, а его коллега тушится.

Решения, мягко сказать, далеки от идеала

PS: Бля... То то я смотрю что-то знакомое... icinga форк нагиоса со всемы вытакающими плюсами и минусами...

Re: Децентрализованный мониторинг

Добавлено: 13 окт 2010 17:46
hex
Ну да, это клон. Типа сделаем как nagios, только лучше )
Dizelsky писал(а):Никакого обмена конфигами, то есть при появлении новой железки её придется заводить дважды
Блин, в ломы его ставить, тестировать. Но если обмена конфигами нет - это epic fail :) А обещанное упрощенное конфигурирование не видел? В принципе не смертельно, конфиги всегда можно в cfengine запихнуть и хоть на 10 серваков раскидывать )