LINUX.ORG.RU
ФорумAdmin

Мониторинг dmesg/top/iotop/etc удалённых машин

 ,


6

10

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

После перезагрузки мы никак не узнаем, что с ними было на момент зависа. Кроме вариантов с munin и т.п., но этого мало.

Лобовое решение, приходящее в голову — открыть на локальной машине screen (это чтобы не мешалось под рукой) и вывести там с удалённой машины через ssh постоянные top (можно сразу несколько, скажем, с сортировкой по процессору, по памяти), iotop, sensors, watch 'dmesg -T| tail -n 30' и т.п.

То есть, когда удалённая машина уйдёт в аут, ssh-сессии отвалятся, на экране останется последнее переданное состояние. Возможно, этой информации хватит для анализа.

Сейчас так и сделал, но на будущее хочется таким образом мониторить множество машин.

Можно написать скрипт, запускающий такой зоопарк автоматически.

Но не велосипедостроение ли это? Может, есть готовое и более удобное решение?

★★★★★

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

Дык, это уже другой вопрос :) А тут и первого хватит, чтобы понять, что у munin иные задачи :)

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

Немного оффтопик, но просто уточнить хочу пару моментов для сравнения collectd VS munin.

Можно. Только он тогда все ресурсы машины сожрёт :)

Ресурсы какой машины? В collectd есть отложенная запись в RRD (на стороне сервера).

Раз в 5 минут десяток-другой секунд обработки потерпеть можно

Что происходит во время обработки?

Ну и придётся ручками RRD-базы переконфигурировать. Они по дефолту настроены на минимальную гранулярность в 5 минут.

В collectd так же. Отличие только в том, что базы создаются по приходу первого UDP пакета от клиента. То есть их можно просто удалить и они пересоздадуться автоматически.

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

но плагина к нему все равно нет

верно, но меньший heartbeat позволит увидеть состояние ближе к зависону. 5 минут это очень-очень много.

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

Осталась мелочь — реализовать возможность агенту прожить ещё до 5 минут на умершем сервере, чтобы он смог отдать данные по запросу наружу :)

Если там действительно kernel panic, а не проблемы с железом, то пример уже назывался - kdump. При старте сервера резервируется ~ 256Мб памяти, туда сразу загружается второе ядро с персональным ramdisk'ом ( он создаётся автоматом скриптами из пакета с kdump ). После паники «основное» ядро передаёт управление «резервному» «crash» ядру. С единственной задачей - собрать дамп и записать/отправить его куда было сказано в конфиге kdump'а при создании ramdisk'а

update. Да, crash kernel точно так же с нуля инициализирует железо, поэтому может быть проблема с некоторыми контроллерами. Например, с hp smart array. Универсальное решение - писать дамп не на диск, а на удалённый сервер по ssh

update2. Хотя бы подключи клавиатуру до падения.. Если после падения будет мигать индикаторами - точно паника.

router ★★★★★
()
Последнее исправление: router (всего исправлений: 2)
Ответ на: комментарий от gh0stwizard

Минус решения: потеря производительности.

А в чём потеря, кроме небольшого участка памяти?

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

верно, но меньший heartbeat позволит увидеть состояние ближе к зависону. 5 минут это очень-очень много.

состояние увидеть - ок.
как узнать, какой процесс виноват?

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

update2. Хотя бы подключи клавиатуру до падения.. Если после падения будет мигать индикаторами - точно паника.

к удаленному серверу или вдс? клавиатуру?

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

update2. Хотя бы подключи клавиатуру до падения.. Если после падения будет мигать индикаторами - точно паника.

Клавиатура есть. Вообще, полноценная консоль там. С включённым дисплеем. Мёртвый вис с переходом БП в режим пониженного потребления и обесточниванием матери.



В общем, методом научного тыка удалось с вероятностью стермящейся к 100% понять, что машину, с которой начался топикстарт, вешают иксы. Запускаешь без иксов — по несколько суток работает без нареканий. Дольше пока не гонялось, т.к. технические рестарты.

Придётся дочке форсировать обучение чтению, чтобы мультики по DLNA запускать по названиям, а не по картинкам из Gnome :) Ну, или мне не лениться прописывать превьюшки к новым мультикам для minidlna.

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

а что тебе мешает POSTить это на какойнить движок PHP+Mysql?

Ну, top'ы/sensors/dmesg/etc в screen'е гораздо эффективнее :)

Вопрос был на тему не велосипедить, а нет ли готового.

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

Судя по топику, зависает сейчас временный сервер, запущенный дома у Крона.

Угу, именно так. Хотя задача интересна и в общем случае, так как, конечно, бывало такое и с чисто удалёнными серверами.

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

screen и ssh уже готов

См. первое сообщение темы :)

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