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

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

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

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

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

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

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

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

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

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

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

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

netconsole

This module logs kernel printk messages over UDP

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

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

Тоже подпишусь.

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

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

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

Что ещё?

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

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

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

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

Еще есть sa (system accounting). Продвинутый top.

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

А ulimit?

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

1. nmon -f
2. sar
+pmap

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

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

2)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

мониторь статистику заббиксом.

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

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

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

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

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

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

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

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

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

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

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

Monit/mmonit или munin

или munin

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

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

munin

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

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

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

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

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

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

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

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

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

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