ps мониторинг + график

Как вы себе этот график представляете? Обычно рисуют графики общей загрузки системы (процессор, память), там понятно что рисовать. А процессы, они ведь повляются/завершаются, в каком виде это отображать?

Munin /thread

Или что бы такое легковесное поставить, чтобы стату по процессам сбивала и график рисовала ?

( скрипт perl или awk ) + graphviz

типа как netflow :)

Главное, чтобы красиво было? Чтобы повешать на стену большую панель и показать начальству, что идёт мониторинг :-)

Причем тут красиво? NfSen полльзовался? Там общий график и 5-минутные сборки топ-статистики по трафику или потокам. Ну или за период времени кратный 5 минут. Ну и здесь так же можно - статистика по процессам за 5 минут на выбор и общий график суммарной загрузки CPU/mem

Ну и здесь так же можно - статистика по процессам за 5 минут

Смотри сначала, какие данные сохраняет ТС, а потом пиши про NfSen, потому, что NfSen получает весь поток Netflow и обрабатывает его фильтрами, а ТС хочет сохранять в файл только 20 процессов, наиболее жрущих процессор в данный момент, причём без PID'а, только имя. И не понятно, они эти данные хочет группировать по задачам (http-сервер, smtp-сервер и т.д.) или по процессам или что? Вот у него в файле будет 10 строк с ″/usr/sbin/httpd″, каждый по 5% процессорного времени и ещё ″perl″, который отдельно, но на самом деле cgi-скрипт. Как это отображать?

upd. ″В файле″, в смыле, в одном временном отсчёте, будет несколько процессов с одинаковым именем.

Смотри сначала, какие данные сохраняет ТС

Думаю ТС попытался примерно обрисовать, что ему надо.

NfSen получает весь поток Netflow и обрабатывает его фильтрами, а ТС хочет сохранять в файл только 20 процессов

Не думаю, что для ТС принципиально сохранять только 20. Хотя, в качестве оптимизации этого гипотетического протокола можно и ограничить таким образом объём пересылаемых данных.

Вот у него в файле будет 10 строк с ″/usr/sbin/httpd″

Как простое решение можно тупо суммировать статистику для одноименных процессов. Будет нехватать этого - можно и параметризацию учитывать. И фильтровать потом по ней.

upd
netflow ведь тоже детализацию выше L4 (tcp/udp) не учитывает, и ничего, всеравно пользуемся

Zabbix [/thread]

Не думаю, что для ТС принципиально сохранять только 20.

Но вопрос то он задал именно так, типа вот я, тут такие данные насобирал, что по ним можно изобразить?

Мы тут сейчас пытаемся что-то решить за ТС, хотя ему бы лучше внятно объяснить, что именно он хочет получить на выходе и зачем ему это нужно.

Я просто в одном месте видел, как админы в своей комнате на стену прилипили панель около 40", пустили на неё отображение графиков NfSen или чего-то похожего, и городо показывали начальству, что у них тут крутая система мониторинга трафика, типа им всё видно. Ну, а это начальство это же повторило/показало вышестоящему начальству. Всем же нравятся красивые непонятные картинки. А то, что там выводятся только общие данные (загрузка граничного маршрутизатора по интерфейсам, без деления по типу трафика), да и сидят в той комнате спиной к этой панели — это не важно.

Есть сабжевый процесс, назовём его pr1, есть вторичные pr2,...prN, так вот события в pr1 начали лагать. Мне надо узнать, что в критические моменты жрёт ресурсы. Или это сам pr1, или вторичные.

Построение графика подразумевает значение какого-либо параметра во все временные отсчёты. Если у вас у всех рассматриваемых процессов известны имена, то и нужно из списка процессов грепать их по именам, а не top20 по загрузке процессора. Или просто выводить на график сколько потребляет pr1 и общую загрузку процессора.

А какие Вы использовали средства мониторинга? Есть что-нибудь, чтобы аудит (хотя бы кто кого когда родил) по процессам красиво проводить?

Короче если задача одноразовая, можно сделать так: Ставишь к примеру zabbix, он рисует график состояния CPU/Memory/DiskIO/Network etc, а параллельно с ним кроном ежеминутно дергаешь свои скрипты, которые валят свой выхлоп в соответствующие логи. Потом смотришь когда заббиксовые графики начинают показывать ахтунг и открываешь свои логи за это время, за минуту найдешь виновного.
Да если и не одноразовая, просто настрой ротацию логов в logrotate