Vladivostok Linux User Group

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

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

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

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

ganglia, да, но не то что надо.

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

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

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

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

Dizelsky писал(а):Шалом, котики.

/me запасся попкорном в ожидании очередного велосипеда на подводных крыльях.

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

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

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

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

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

hex писал(а):запасся попкорном в ожидании очередного велосипеда на подводных крыльях

как верно подмечено

hatred писал(а):чудная прелесть как RESOURCE string

оооо!!!!

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

гавнюк ты.

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

hatred писал(а):гавнюк ты.

еще какой...

"чудная прелесть как RESOURCE string" редко где реализована через руки, jabber как транспорт отходит на второй план.

hex писал(а):Вот если тебе надо ещё и пачку сервисов проверять

угу, парочку сервисов, парочку интерфейсов, наполняемость БД, наполняемость и ротацию файлов, присутствие неизвестных mac в бродкасте, аномалии по трафику и прочие глупости, что в голову придут... Отсюда же и диференциация сообщений по приоритетам, разные получатели. Nagios поможет, но он уродско конфигурируется и туго кластеризуется.

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

Dizelsky писал(а):Nagios поможет, но он уродско конфигурируется и туго кластеризуется.

Глянь на http://www.icinga.org/, заодно нам расскажешь, чем он от Nagios отличается. Говорят, конфигурируется проще.

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

hatred писал(а):как сервер будет мониторить, если он от сети отвалился

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

hex писал(а):

Dizelsky писал(а):Nagios поможет, но он уродско конфигурируется и туго кластеризуется.

Глянь на http://www.icinga.org/, заодно нам расскажешь, чем он от Nagios отличается. Говорят, конфигурируется проще.

Может где-то и проще, но особой разницы с нагиосом не увидел.
Метод "Redundant and Failover Network Monitoring" у них это вообще ппц.
Redundant - две копии этого монстра седят друг за другом. Один из них мастер. У слейва отключают notification пока мастер жив. Никакого обмена конфигами, то есть при появлении новой железки её придется заводить дважды
Failover - Те же яйца, только слейв в это время выключен и при включении он уже становится мастером, а его коллега тушится.

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

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

Ну да, это клон. Типа сделаем как nagios, только лучше )

Dizelsky писал(а):Никакого обмена конфигами, то есть при появлении новой железки её придется заводить дважды

Блин, в ломы его ставить, тестировать. Но если обмена конфигами нет - это epic fail :) А обещанное упрощенное конфигурирование не видел? В принципе не смертельно, конфиги всегда можно в cfengine запихнуть и хоть на 10 серваков раскидывать )