Децентрализованный мониторинг
Децентрализованный мониторинг
Шалом, котики.
Собственно, есть N серверов на линуксах, где N>1. Надо эту группу мониторить - место, cpu, процессы и и прочие глупости. Бида классических систем мониторинга - центральный сервер. Если он мрет - об этом вряд ли можно узнать оперативно. Как вариант - настроить костылик для мониторинга центрального сервера. Но это некрасиво, неэффективно и так далее...
Что хочу сделать - децентрализованная кластерная система мониторинга. Все сервера равноправны и все следят друг за другом. В общем отказоустойчивая пепяка. В алгоритмах вопросов нет, дело на пол часа. Проблема в транспорте.
Есть ли у кого наработки/опыт/идеи по передаче произвольных строк между серверами/процессами?
Напрашивается XMPP, т.к. админу в таком случае удобно получать сообщения, но как в таком случае посадить несколько клиентов на один аккаунт (регать для каждого новый акк - моветон).
Целый web-сервер на такие мелочи отдавать - жаба давит, да и несекурно это.
Какие еще протоколы можно тут присунуть?
ЗЫ: Предвижу зоопарк из всяких солярисов, хпуксов и прочих бздей, так что ищу наиболее универсальный метод.
Собственно, есть N серверов на линуксах, где N>1. Надо эту группу мониторить - место, cpu, процессы и и прочие глупости. Бида классических систем мониторинга - центральный сервер. Если он мрет - об этом вряд ли можно узнать оперативно. Как вариант - настроить костылик для мониторинга центрального сервера. Но это некрасиво, неэффективно и так далее...
Что хочу сделать - децентрализованная кластерная система мониторинга. Все сервера равноправны и все следят друг за другом. В общем отказоустойчивая пепяка. В алгоритмах вопросов нет, дело на пол часа. Проблема в транспорте.
Есть ли у кого наработки/опыт/идеи по передаче произвольных строк между серверами/процессами?
Напрашивается XMPP, т.к. админу в таком случае удобно получать сообщения, но как в таком случае посадить несколько клиентов на один аккаунт (регать для каждого новый акк - моветон).
Целый web-сервер на такие мелочи отдавать - жаба давит, да и несекурно это.
Какие еще протоколы можно тут присунуть?
ЗЫ: Предвижу зоопарк из всяких солярисов, хпуксов и прочих бздей, так что ищу наиболее универсальный метод.
Re: Децентрализованный мониторинг
ganglia (http://ganglia.sourceforge.net/)
Хосты собирают и передают инфу как угодно. Можно сделать и чтоб каждый знал о каждом. Инфа снимается в виде XML простым соединением через telnet к заданному порту. Есть и всякие обработчики, но с ними не возился, не знаю.
Хосты собирают и передают инфу как угодно. Можно сделать и чтоб каждый знал о каждом. Инфа снимается в виде XML простым соединением через telnet к заданному порту. Есть и всякие обработчики, но с ними не возился, не знаю.
Re: Децентрализованный мониторинг
ganglia, да, но не то что надо.
Как я желаю видеть это на практике - Есть некое облако уже работающих серверов, вот появился новый и мне надо его быстро включить в мониторинг. Я копирую на сервер скрипт (! именно скрипт, ибо, как показывает практика, это самый удобопортируемый вариант), запускаю его всего с 2мя параметрами - пароль облака и ip одного из элементов облака. Всё остальное вполне может пройти на автомате - импорт конфигов, добавление в облако - всё это задачи вполне тривиальные. Дальше они смотрят друг за другом, оповещают о проблемах админа и обмениваются инфой о состоянии друг друга (для истории).
Нужно - безопасный и быстрый транспорт + прямые руки.
с ganglia картина будет далека от описанной...
Как я желаю видеть это на практике - Есть некое облако уже работающих серверов, вот появился новый и мне надо его быстро включить в мониторинг. Я копирую на сервер скрипт (! именно скрипт, ибо, как показывает практика, это самый удобопортируемый вариант), запускаю его всего с 2мя параметрами - пароль облака и ip одного из элементов облака. Всё остальное вполне может пройти на автомате - импорт конфигов, добавление в облако - всё это задачи вполне тривиальные. Дальше они смотрят друг за другом, оповещают о проблемах админа и обмениваются инфой о состоянии друг друга (для истории).
Нужно - безопасный и быстрый транспорт + прямые руки.
с ganglia картина будет далека от описанной...
- hatred
- Global Moderator
- Сообщения: 1205
- Зарегистрирован: 08 июн 2006 00:32
- Откуда: Владивосток
- Контактная информация:
Re: Децентрализованный мониторинг
Есть у жабера такая чудная прелесть как RESOURCE string, которая делает аккаунт вида:Dizelsky писал(а):Напрашивается XMPP, т.к. админу в таком случае удобно получать сообщения, но как в таком случае посадить несколько клиентов на один аккаунт (регать для каждого новый акк - моветон).
Целый web-сервер на такие мелочи отдавать - жаба давит, да и несекурно это.
Какие еще протоколы можно тут присунуть?
login@jabber.server/RESOURCE, то что всякие укуренные клиенты типа Google Talk пихают туда рандомную ахинею, не отменяет её функциональности. С разные RESOURCE стрингами позволяется несколько подключений от одного аккаунта... ну или как у тебя сервер настроент (к примеру, jabber.ru такое позволяет). Более того, если, клиент может запросить переслать ему сообщения, которые были адресованы другим RESOURCE и тем самым посмотреть что там творилось, пока ты ехал на работу (было полезно - дома жабер забывал выключить). Ну и... когда придет сообщение, будет в заголовке видно - от кого. А отсылалка sendxmpp как-то так, консольная. а скрипты для локальных проверок можно своровать у Nagios, благо это простые консольные программки. Всё это слепить посредством bash-script и rsync и должно быть вселенское счастие. Ну и да, про почту не забываем, тоже транспорт :-D
Прошли времена когда на элементарные вопросы можно было отвечать man <что-то там> (с) из сети
Hatred's Log Place | My GitHub repos | My Gitlab repos
Hatred's Log Place | My GitHub repos | My Gitlab repos
Re: Децентрализованный мониторинг
/me запасся попкорном в ожидании очередного велосипеда на подводных крыльях.Dizelsky писал(а):Шалом, котики.
Что мониторить собираешься, пинг? Если сервак пингуется - это значит только то, что на нём жив стек TCP/IP. Иногда это единственное, что остается в живых. Или вообще другая машина себе этот IP захавала.
Сервисов, которые твои серваки будут пинговать со всех материков планеты за смешные деньги - вагон и маленькая тележка.
Вот если тебе надо ещё и пачку сервисов проверять - всё становится забавнее. Во первых, одним запуском скрипта для подключения не отделаешься. Во вторых, тебе понадобится держать распределенную базу данных. В третьих, серверам придётся проводить регулярную перекличку и распределять между собой задания на проверку/рассылку. В четвертых, решить проблему сплита на два (и более) облака. В пятых, решить проблему безопасности. Потому как поимевший любой из серверов автоматом имеет всю сеть. Дальше пункты придумывай сам )
Я свои серваки держу под контролем такой связкой: nagios на одной машине и cfengine на другой. Нагиос сообщает о проблемах, cfengine кофигурит серваки и сообщает о проблемах с nagios (при этом автоматом пытается его перезапустить). Да, разумеется nagios одним глазом следит за cfengine. И есть ещё сторонний nagios, который приглядывает за моими cfengine и nagios. Ещё есть машинка с cacti, но она так, для отслеживания здоровья пациентов.
Кстати, сервер под контроль cfengine добавляется именно копированием и запуском одного скрипта. Думаю, что при желании можно заставить cfengine регистрировать новые сервера на nagios, но ну его нафиг автоматизировать задачу, которая у меня раз в полгода всплывает )
Re: Децентрализованный мониторинг
как верно подмеченоhex писал(а):запасся попкорном в ожидании очередного велосипеда на подводных крыльях
![Smiley :)](./images/smilies/smiley.gif)
оооо!!!!hatred писал(а):чудная прелесть как RESOURCE string
на этом концерт окончен
/me снова покрывается на N лет
- hatred
- Global Moderator
- Сообщения: 1205
- Зарегистрирован: 08 июн 2006 00:32
- Откуда: Владивосток
- Контактная информация:
Re: Децентрализованный мониторинг
гавнюк ты.
hex: у меня работало почти так же.
hex: у меня работало почти так же.
Прошли времена когда на элементарные вопросы можно было отвечать man <что-то там> (с) из сети
Hatred's Log Place | My GitHub repos | My Gitlab repos
Hatred's Log Place | My GitHub repos | My Gitlab repos
Re: Децентрализованный мониторинг
еще какой...hatred писал(а):гавнюк ты.
![Smiley :)](./images/smilies/smiley.gif)
"чудная прелесть как RESOURCE string" редко где реализована через руки, jabber как транспорт отходит на второй план.
угу, парочку сервисов, парочку интерфейсов, наполняемость БД, наполняемость и ротацию файлов, присутствие неизвестных mac в бродкасте, аномалии по трафику и прочие глупости, что в голову придут... Отсюда же и диференциация сообщений по приоритетам, разные получатели. Nagios поможет, но он уродско конфигурируется и туго кластеризуется.hex писал(а):Вот если тебе надо ещё и пачку сервисов проверять
пока что больше вопросов чем ответов... Думаю как лучше сделать
Re: Децентрализованный мониторинг
Глянь на http://www.icinga.org/, заодно нам расскажешь, чем он от Nagios отличается. Говорят, конфигурируется проще.Dizelsky писал(а):Nagios поможет, но он уродско конфигурируется и туго кластеризуется.
- hatred
- Global Moderator
- Сообщения: 1205
- Зарегистрирован: 08 июн 2006 00:32
- Откуда: Владивосток
- Контактная информация:
Re: Децентрализованный мониторинг
я думал ты хоть свой jabber сервер имеешь... кстати jabber.ru вроде как нормально строки поддерживает. Кстати, а как сервер будет мониторить, если он от сети отвалился? ![Smiley :)](./images/smilies/smiley.gif)
![Smiley :)](./images/smilies/smiley.gif)
Прошли времена когда на элементарные вопросы можно было отвечать man <что-то там> (с) из сети
Hatred's Log Place | My GitHub repos | My Gitlab repos
Hatred's Log Place | My GitHub repos | My Gitlab repos
Re: Децентрализованный мониторинг
Если "он" это сам объект монторинга, то за него это должны сделать соседи из его же cloud`аhatred писал(а):как сервер будет мониторить, если он от сети отвалился
Если "он" это jabber сервер, то это решается:
a) собственным сервером. То есть один сервер-объект - один jabber сервер == накладно, громоздко и некрасиво
b) уходом на децентрализованный транспорт, что в контексте децентрализованного мониторинга на порядок лучше.
Re: Децентрализованный мониторинг
Может где-то и проще, но особой разницы с нагиосом не увидел.hex писал(а):Глянь на http://www.icinga.org/, заодно нам расскажешь, чем он от Nagios отличается. Говорят, конфигурируется проще.Dizelsky писал(а):Nagios поможет, но он уродско конфигурируется и туго кластеризуется.
Метод "Redundant and Failover Network Monitoring" у них это вообще ппц.
Redundant - две копии этого монстра седят друг за другом. Один из них мастер. У слейва отключают notification пока мастер жив. Никакого обмена конфигами, то есть при появлении новой железки её придется заводить дважды
Failover - Те же яйца, только слейв в это время выключен и при включении он уже становится мастером, а его коллега тушится.
Решения, мягко сказать, далеки от идеала
PS: Бля... То то я смотрю что-то знакомое... icinga форк нагиоса со всемы вытакающими плюсами и минусами...
Re: Децентрализованный мониторинг
Ну да, это клон. Типа сделаем как nagios, только лучше )
Блин, в ломы его ставить, тестировать. Но если обмена конфигами нет - это epic fail :) А обещанное упрощенное конфигурирование не видел? В принципе не смертельно, конфиги всегда можно в cfengine запихнуть и хоть на 10 серваков раскидывать )Dizelsky писал(а):Никакого обмена конфигами, то есть при появлении новой железки её придется заводить дважды