LINUX.ORG.RU
ФорумAdmin

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

 ,


6

10

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

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

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

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

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

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

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

★★★★★

Может, просто, настроить центральный сервер логирования и пусть машины шлют туда логи. Для сбора printk messages ядра настой netconsole.

Состояние системы можно например nagios'ом или icinga, настроив так, чтобы делал запросы чаще.

hope13 ★★★ ()

почему не использовать Zabix c использованием фильтров на том же bash для нестандартных вещей вроде top а sensors может спокойно писать в logger который агрегировать и просматривать удобным способом опять таки с возможностью фильтровать?
по моему это очень логичное решение.

system-root ★★★★ ()

интересный вопрос. подписался на комменты. надеюсь увидеть решение.

А чем не устраивает collectd/munin ? Если статистика (rrd) хранится на центральном сервере, то она не потеряется в файловом кэше при зависоне\рестарте. Например, в collectd есть возможность увидеть disk IO per process (для выбранных процессов) и общий disk IO.

Имхо, принимать syslog/dmesg сообщения имеет смысл только на физ.серверах. Виртуалки мрут молча.

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

Ну, для sensors Zabbix пойдёт. Вот для портянок логов — это же явно не его профиль. Не говоря уже про то, что нужно контролировать часто, буквально каждые секунду-две, процесс облома можнт развиваться стремительно. А вот логгировать те же top или iotop как раз нафиг не нужно. Достаточно последнего состояния.

По той же причине не подходит упомянутый позже munin.

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

Имхо, принимать syslog/dmesg сообщения имеет смысл только на физ.серверах.

Естественно, речь о физических серверах.

KRoN73 ★★★★★ ()
Последнее исправление: KRoN73 (всего исправлений: 1)

Недавно вжная виртуалка зависла - top, dmesg, iotop не дают эффекта - avg 70. Сходил покурить - avg 27 - вот и верь мин. здраву после этого.

bug ()
Ответ на: комментарий от zolden

This module logs kernel printk messages over UDP

Совсем не та задача.

KRoN73 ★★★★★ ()

плюсую вопрос.
разве до сих пор нет легковесного решения, которое мне после критичной нагрузки расскажет:
1. какой процесс вызвал проблему
2. во что уперся этот процесс
? хочу поставить такое на пачку вдс и выкинуть munin.

xtraeft ★★☆☆ ()
Последнее исправление: xtraeft (всего исправлений: 1)
Ответ на: комментарий от pekmop1024

а похоже нет такого.
все советы упираются в «сиди и смотри перед падением, что грузит систему».
ищу уже давно :)

xtraeft ★★☆☆ ()

Ну, раз такого нет, давайте коллективным разумом ещё подумаем, что полезно контролировать по моему методу, кроме top/iotop/sensors/dmesg?

Ну, наверное, syslog можно добавить. Хотя с ним сложно — если на машине куча виртуальных контейнеров, это ж с каждого смотреть надо, фиг знает, откуда может полезть :)

Что ещё?

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

Ну, раз такого нет, давайте коллективным разумом ещё подумаем, что полезно контролировать по моему методу, кроме top/iotop/sensors/dmesg?

ну вот у меня допустим на пачке вдс какой то процесс (php, вебсервер или что-то еще) отжирает уйму памяти и потом оом-киллер убивает все вплоть до sshd.

насколько помню, даже в syslog нельзя найти тот процесс, который был критической точкой.

а как это все контролировать для пачки вдс/серверов - непонятно.
самописные костыли использовать очень не хочу, и удивлен, что нет ничего готового.

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

какой то процесс (php, вебсервер или что-то еще) отжирает уйму памяти

А ulimit?

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

Через ulimit не отрегулировать пожирание процессами пахапе памяти. Попробуйте лучше механизм cgroup.

AnDoR ★★★★★ ()

1) по перечисленным объектам мониторинга.

Всё кроме dmesg можно прикрутить к системе мониторинга. Для dmesg - настроить rsyslog/syslog-ng на удалённый сервер.

2)

когда они по непонятной причине уходят в даун.

я бы предположил что на них случается kernel panic, и настроил kdump на слив дампа на удалённый ssh. Цена вопроса - 256 Мб памяти и один ребут на каждый сервер

Как выглядит «уходят в даун»?

3) а в логах ilo/rsa есть что? Может там аппаратная проблема.

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

Как выглядит «уходят в даун»?

Текущий вариант такой: http://www.balancer.ru/g/p3226122

а в логах ilo/rsa есть что?

iLo — это ж чисто HP-шная штука? И что конкретно по rsa понимается?

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

iLo — это ж чисто HP-шная штука?

Ок, тогда так - «в логах management module» :)

И что конкретно по rsa понимается?

А это чисто ibm'ная штука :\

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

Ок, тогда так - «в логах management module» :)

Один фиг, нет такого :)

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

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

имелось ввиду logstash, graylog2 - хоть каждую секунду по фильтру смори что происходит

А вот логгировать те же top или iotop как раз нафиг не нужно. Достаточно последнего состояния

когда произойдёт перезагрузка или зависание ты увидишь на сводном графике вообще всё что нужно. именно для этого и создавали zabbix и вбухнули туда миллионы на разработку. всё на одном экране браузера, смотришь корреляцию и вперёд.
короче говоря top/iotop/iftop/sockstat/syslog/sensors/dmesg решают две системы, это logstash и zabbix

потом оом-киллер убивает
даже в syslog нельзя найти тот процесс

киллер говорит кого убил и когда.
http://habrahabr.ru/post/165059/#comment_5763777
люди пользуются логоми и находят проблемы.
с ситуациями чтоб оом-киллер убивал ssh потому что в виртуалке ПХП - из области фантастики

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

system-root ★★★★ ()
Последнее исправление: system-root (всего исправлений: 1)

atop'ом пиши логи, потом прокручивай, там много данных, по сравнению с обычным top'ом, очень много.

/usr/bin/atop -a -w /var/log/atop/atop_20130828 $INTERVAL [$SAMPLES]

sdio ★★★★★ ()

У меня рсислоги аккуратненько отправляются на один сервачок.
Дабы не получилась каша, была установлена вэб-морда.
Плюс настроена icinga.

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

мне надо знать, какой процесс отожрался и привел к зависанию.

xtraeft ★★☆☆ ()

Если задача возникает не впервые, то рекомендую озадачиться более глобально, поставив систему мониторинга. И уже в ней настроить периодический сбор максимального количества параметров как OC, так и железа. Все современные мониторинги поддерживают custom-скрипты, поэтому снимать показатели можно с чего-угодно.

И потом можно будет отслеживать даже долгосрочные тенденции к падению того или иного сервера.

Chumka ★★★ ()

Года два назад мне, где-то тут, подсказали про http://www.xymon.com/,
как про свободный аналог Big Brother. В общем-то, логи он пасти может.

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

Через ulimit не отрегулировать пожирание процессами пахапе памяти

это решается через лимит памяти на процесс php (memory_limit) и лимитом на количество одновременно запущенных пыхпыхов (реализация зависит от метода, которым запускается пыхпых).

В качестве централизованной собиралки и анализатора логов очень рекомендую Graylog2 как сервер, на клиентах настраиваешь rsyslog для передачи сообщений на удаленный хост с грейлогом. чтобы слать грейлогу выводы команд, можно юзать это: http://logstash.net/docs/1.1.13/inputs/exec

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

как про свободный аналог Big Brother. В общем-то, логи он пасти может.

Имея большой опыт работы с xymon, вполоть до изучения исходников, могу с уверенностью сказать - удалённый syslog он не заменит. Хотя бы потому, что

а) клиент шлёт данные раз в 5 минут ( запускать чаще можно, но этот интервал много где захардкоден и работать не всё будет как ожидалось. А крону нужно чуть ли не realtime

б) если данные в лог поступают быстро ( ЕМНИП, больше 10 кбайт за эти же пять минут ), то на сервер будет отправлено не всё ( только последние 10 кб ). Можно шаманить с ignore и trigger в client-local.cfg, но абсолютно надёжного мониторинга логов не получить.

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

Это понятно, но, во-первых, можно на нужный хост ставить тоже сервер, который уже готовое сливать будет (если я тут не ошибаюсь), во-вторых, ignore таки рабочий вариант. А про отмену удалённого syslog я не говорил. Одно другому не мешает.

AS ★★★★★ ()

Можно настроить kdump + kexec (на редхате это делает очень просто) чтобы в момент зависона дампалось ядро и опционально производился авторебут. В итоге ты получишь файл-стек, который можно будет потом разбирать по кусочкам.

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

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

Это и есть dmesg по сети, причём без userspace, что увеличивает шансы получить сообщения о панике ядра.

ИМХО, нет смысла собирать и анализировть информацию о процессах (top) и дисковой активности в случае таких зависаний, когда система не реагирует на внешние воздействия. Лучше уж нагружать её по многу часов тестами, добиваясь её зависания.

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

ИМХО, нет смысла собирать и анализировть информацию о процессах (top) и дисковой активности в случае таких зависаний, когда система не реагирует на внешние воздействия.

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

резюмирую вкратце: как узнать, какой процесс сожрал все ресурсы и убил сервер?

xtraeft ★★☆☆ ()

ТС амиго, пиши удаленный лог либо средствами syslog либо другими средствами НО никак ты не сможешь увидеть последнее сообщение которое появилось уже после падения сети, то которое на экране появилось. Это только в живую. что бы это видеть обычно машины подключают в IP-KVM в ДЦ

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

Это только в живую

Вот как раз практика показывает, что на экране ты вживую увидишь меньше, чем успеет последнего уйти по сети :D Это ж не BSOD… Большинство «наводящих» данных на экран вообще никогда не выводится.

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

когда падает в корку ядро, то иной раз только там видно.

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

Увы, у меня обычно причины были всегда другие :)

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

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

в случае таких зависаний

С другой стороны — комп дважды уже странно выключался. Что утром сегодня, что сейчас. Просыпаюсь — индикатор питания на корпусе не горит, индикатор на матери светится, кулер процессора крутится на малых оборотах, ни на что не отзывается. Кнопкой питания не запускается. Долгое нажатие на кнопку питания, машина выключается целиком, включаешь — работает как ни в чём ни бывало.

Хотел бы я посмотреть на процесс в userspace, который способен так сожрать все ресурсы, в том числе и питание для индикаторе на корпусе :-)

В случаях разбушевавшегося OOM-killer, или зашкаливающего LA, система всё равно подаёт признаки жизни, (NumLock, ping) и там данные top'а имеют смысл. Готовой такой системы я не знаю, раньше что-то велосипедил (скрипты), сейчас у меня фактически один сервер, не так актуально.

Почему нет готовой системы не знаю. Так, с точки зрения работы при большом LA и активном swap´е один статически слинкованый бинарник должен быть надёжнее скриптов.

mky ★★★★★ ()

Есть вис. Чёрный экран, отсутствие всякого видео вывода. В логах, оставшихся в screen'е, ничего подозрительного кроме 100% загрузки CPU в последнюю секунду (или какой там интервал обновления у nmon).

KRoN73 ★★★★★ ()

Собрать ядро с отладкой и заюзать netconsole пробовали?

Pinkbyte ★★★★★ ()

1) НОРМАЛЬНЫЙ МОНИТОРИНГ
2) отправка логов по сети на вебморду, не помню как она называется.

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

1) НОРМАЛЬНЫЙ МОНИТОРИНГ

какой легковесный посоветуешь?

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

или munin

«Кроме вариантов с munin и т.п., но этого мало.» :)

munin везде установлен. Но он под имеющуюся задачу совсем не подходит. Он для другого. По нему можно увидеть, что винты, там, перегрелись, или в своп машина ушла и умерла. Но мгновенный отказ того же контроллера HDD ты на нём никак не обнаружишь.

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

munin

к нему есть плагин, который покажет какой процесс привел к умиранию сервера?

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

к нему есть плагин, который покажет какой процесс привел к умиранию сервера?

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

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

прожить ещё до 5 минут на умершем сервере

а в munin, что, этот интервал нельзя уменьшить? В collectd, например, это называется heartbeat и его можно выставить хоть 5 сек. И да, клиент отсылает UDP центру, а не центр запрашивает.

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

а в munin, что, этот интервал нельзя уменьшить?

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

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

а в munin, что, этот интервал нельзя уменьшить?

Можно. Только он тогда все ресурсы машины сожрёт :) Раз в 5 минут десяток-другой секунд обработки потерпеть можно, но если хотя бы два раза в минуту — то это песец будет. И всё равно слишком редко будет обновлять записи.

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

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