LINUX.ORG.RU

[мониторинговая система] Выполнение команд на удаленных хостах: best practices


0

0

Пишу замену monit ( в основном, чтобы управлять группой серверов из одного места и конфигурировать на полноценном ЯП ).

Т.к. приложение не столько система мониторинга, сколько автоматическое реагирование на некоторые события, главная часть - выполнение команд по событию, в т.ч. на удаленных хостах. Чтобы максимально все упростить, на удаленных машинах не устанавливается никаких «агентов», слушающих команды.

Сейчас это делается с помощью постоянного ssh-соединения( на каждый хост по треду), где по событию происходит «system(sudo command)», sudo выполняет команду от нужного пользователя ( чаще всего не рута, сервисы запущены от какого нибудь web-server, или mysql, etc).

Хотелось спросить, может я что-нибудь упускаю, может есть другие, более прямые способы?

Спасибо.

★★
Ответ на: комментарий от Kpoxman

Пишу на руби, в качестве прототипа и эксперимента: на руби большие проблемы с долгоиграющими процессами из-за того, что он не отдает память в систему. Существующая система мониторинга процессов (http://god.rubyforge.org/) известна тем, что может отжирать до нескольких сотен метров памяти и ее саму приходится мониторить ( ну прям как в той басне, One day a student came to Moon and said: “I understand how to make a better garbage collector."... ).

Мне интересно посмотреть, насколько все плохо и можно ли писать долгоживущие демоны в таких условиях. Если все совсем плохо, перепишу на питоне.

И, кстати, ИМХО по треду не обязательно.


Я это для общего представления, скорее всего будет использоваться пул процессов ( опять же, из-за проблем GC ) или корутин-фиберов.

volh ★★
() автор топика

В качестве агента на серверах возьми стандартный snmpd
Можно собирать данные, выполнять свои скрипты и энтерпрайзненько.

sdio ★★★★★
()
Ответ на: комментарий от sdio

Я почему-то вбил себе в голову, что snmpd может только собирать статистику. Спасибо. Почитал, он еще и поверх SSH может работать, вообще отлично. Да, SNMP один из основных вариантов, но:

1) «exec and sh extensions can only be configured via the snmpd.conf file. They cannot be set up via SNMP SET requests.» - дело труба?

2) весь net-snmp стек какой-то слишком уж энтерпрайзный для моих задач

3) Выполнение скриптов и даже встроенный перл - это отлично, но далеко не всегда так удобно как простое выполнение команд прямо на месте, используя ЯП на котором написана программа и любые данные, которые могут потребоваться ( а не только передаваемые параметры ). Хотя может быть надумано.

4) Опять же, я могу использовать и monit в качестве агента, где управление процессами намного нагляднее, проще и мощнее. Я не нашел как сделать с помощью net-snmp, например, такое: «сколько цпу ест вот этот процесс? если больше 30% => если больше 3 последних проверок => отправить мейл; если больше 5 последних проверок => сделать ему SIGUSR1»

volh ★★
() автор топика
Ответ на: комментарий от sdio

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

Но если интересно, у nagios другая весовая категория. Я не даром в первом сообщении написал, что мне нужен monit, но только для многих хостов в одной центральной конфигурации. Немного забавно, но со всей своей энтерпрайзностью, вот это http://nagios.sourceforge.net/docs/3_0/eventhandlers.html#example - уже лучше, но по большому счету тот же snmpd, вид сбоку. Заранее определенный набор состояний, _внешние_ скрипты, етц. Если Eventhandlers и Externalcommands ( через command_file ) - это все способы, которые существуют в nagios, то мягко говоря, этого недостаточно. Конечно, может быть(скорее всего) я чего-то не понимаю и/или плохо смотрел, но неважно, тред не об этом.

volh ★★
() автор топика

volh> best practices

Ладно:
1. постоянное ssh-соединение — плохо, т.к. избыточно
2. Management server периодически опрашивающий (по ssh) серверы — хорошо для мониторинга и плохо если надо реагировать на серверх на события (убить процесс, почистить ФС, ...)
3. Агенты на серверах (а-ля CRON + ssh как транспорт оповещения Management server) — хорошо ибо автономно, после загрузки правил поведения (если отвалится единственный Management server все продолжат работать)

sdio ★★★★★
()
Ответ на: комментарий от sdio

>1. постоянное ssh-соединение — плохо, т.к. избыточно

Вот, вот оно. А в чем избыточность? Я так понимаю постоянное соединение в смысле трафика лучше чем новые соединения через каждые скажем две минуты? Да и не только трафика, поддерживать соединение почти ничего не стоит. Наверное что-то упустил?

volh ★★
() автор топика
Ответ на: комментарий от volh

Хотелось бы чтоб вы как-то озвучили найденное решение.

irishka
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.