Многие уже видели старенькую схему Брендана Грегга, где каждой подсистеме сопоставлены CLI-утилиты. Она правда полезная, но когда «горит», мы бежим в интернет, а не выискиваем систему и команду. В статье я собрал тулзы с картинки, а также добавил опенсорсных утилит, которые пригодятся для мониторинга.
Сразу отмечу, инструменты, как и на схеме, размещены по подсистемам. Опенсорсные утилиты — в конце каждого раздела я описал коротко, так как подробности можете посмотреть на гитхабе.
Приложения и системные библиотеки
На этом уровне обычно и находится причина зависаний, потому что именно приложения решают, чем грузить ядро и железо. Среди типичных проблем:
один процесс стабильно ест CPU и непонятно, чем именно занят,
приложение «живое», но не отвечает, потому что залипло в системных вызовах,
задержки из-за резолвинга имён, которые выглядят как сетевые проблемы,
утечки ресурсов, чаще всего файловые дескрипторы и сокеты,
короткоживущие дочерние процессы, которые успевают отработать между обновлениями top.
На схеме в этом слое strace, ltrace и gethostlatency. Я добавил сюда ещё journalctl — без него диагностика неполноценна.
Strace отвечает за системные вызовы. Утилита полезна для выяснения того, какие вызовы тормозят приложение и сколько времени тратится в ядре. Самый практичный режим — это сводная статистика по вызовам:
strace -c -p <PID>
Ltrace похож по смыслу, но «смотрит» динамические библиотеки. Пригодится, когда strace не показывает ничего странного, а приложение всё равно ест CPU или работает медленно:
ltrace -f ./myapp
Gethostlatency ловит задержки на разрешении имён. Это тот случай, когда кажется, что проблема в сети, но на деле приложение тупит на DNS. К слову, инструмент из eBPF/BCC, поэтому нужен установленный набор bcc-tools.
sudo gethostlatency
На схеме есть dmesg, но это логи ядра. Если у вас systemd, то падения сервисов, ошибки приложений и рестарты воркеров нужно смотреть в журнале:
journalctl -u <service> -n 200 --no-pager
При анализе проблем используем сверху вниз. Если причину не нашли, юзаем сторонние утилиты:
rr record/replay debugger — инструмент для записи, воспроизведения и отладки выполнения приложений (деревьев процессов и потоков),
bpftrace — инструмент и язык для трассировки, а также для создания кастомных наблюдений через eBPF,
sysdig — универсальный снитчер системных событий,
lnav — лог-вьювер и анализатор журналов,
procps-ng — набор мониторинга для процессов.
Интерфейс системных вызовов и ядро
Если на уровне приложения ничего криминального не видно, значит, идём глубже. Проблемы внутри ядра (например, блокировка в драйвере или проблемная подсистема) обычно проявляются через медленные системные вызовы или высокий процент времени ядра.
На схеме в этом слое perf, ftrace, LTTng, а также набор eBPF/BCC-утилит.
Perf — основной инструмент профилирования. Через него можно посмотреть аппаратные счётчики CPU и понять, какие функции реально «горят». Если наверху функции ядра или драйверов, значит, узкое место уже не в логике приложения.
Общую статистику по всем CPU смотрим через:
perf stat -a -- sleep 2
А профиль конкретного процесса со стеком через:
perf top -g -p <PID>
Ftrace — встроенный трассировщик ядра. Позволяет отследить конкретные события и функции внутри ядра. Например, через trace-cmd можно увидеть, сколько раз вызывается read() и сколько времени он реально занимает внутри ядра:
trace-cmd record -e sys_enter_read -e sys_exit_read trace-cmd report
LTTng — система трассировки для ядра и приложений. Эта утилита используется, когда нужно собрать детальную картину по событиям во времени и сопоставить их между собой. Для этого:
# Создаём сессию sudo lttng create syswide --output=/tmp/lttng-trace # Включаем события ядра (лучше начать с базовых) sudo lttng enable-event -k sched_switch,sched_wakeup sudo lttng enable-event -k block_rq_issue,block_rq_complete sudo lttng enable-event -k net_dev_queue,netif_receive_skb # Запускаем трассировку sudo lttng start # Собираем кусок (например, 30 секунд) sleep 30 # Останавливаем и завершаем sudo lttng stop sudo lttng destroy # Смотрим вывод babeltrace /tmp/lttng-trace
Дальше идут eBPF/BCC-утилиты, которые позволяют быстро ответить на конкретный вопрос. Например, opensnoop (отслеживает open() всех процессов), profile (собираем семплы по частоте), offcputime (суммирует время, проведённое вне процессора), softirqs (отображает время прерываний), runqlen (отображает гистограмму с длинной очереди планировщика), execsnoop (показывает запуск новых процессов), showboost (показывает Turbo Boost по ядрам) и др. Среди интересных сторонних утилит:
Inspektor Gadget — набор утилит для анализа системных вызовов и поведения ядра (особенно в контейнерах).
SystemTap — мощный трассер ядра на языке скриптов.
Файловая система и VFS
На этом уровне проблемы чаще всего связаны не с самим диском, а с тем, как приложения работают с файлами. Массовые открытия и закрытия, постоянные операции с метаданными, тысячи мелких файлов в каталоге, утечки дескрипторов — всё это нагружает VFS и ядро даже при нормальной утилизации диска.
На схеме в этом слое lsof, fatrace, filelife, pcstat, slabtop + точечные утилиты под конкретную ФС вроде ext4slower/ext4dist.
Первое, что стоит проверить — кто и что держит открытым. Для этого подходит lsof.
lsof -p PID lsof +D /path/to/dir
Через -p видно, какие файлы, сокеты и устройства открыты конкретным процессом, а через +D можно посмотреть, какие процессы работают с определённым каталогом. Это помогает в ситуациях, когда лог уже удалён, но место не освобождается, или когда процесс неожиданно упирается в лимит дескрипторов.
Если нужно понять, кто прямо сейчас активно трогает файловую систему, запускаем fatrace — утилита в реальном времени показывает события открытия, чтения, записи и закрытия. Подходит для поиска процессов, которые генерируют постоянный мелкий I/O или регулярно переписывают одни и те же файлы:
sudo fatrace -c
Когда есть подозрение на большое количество короткоживущих файлов, полезен filelife из набора BCC — он показывает процессы, создающие и удаляющие файлы с очень коротким временем жизни. Запускаем через:
sudo filelife
Pcstat показывает статус кэша страниц для указанных файлов. С его помощью можно понять, кешируются ли данные или же постоянно происходит сброс/чтение с диска:
pcstat somefile
Отдельно стоит смотреть на потребление памяти в SLAB-кешах через аналог top — slabtop. Если резко растёт один из кешей, связанный с inode или dentry, это чаще всего указывает на большое количество операций с файлами или на проблемы в конкретной подсистеме.
slabtop
Для глубокой диагностики Ext4 используйте ext4slower и ext4dist из BCC. Они позволяют увидеть задержки конкретных операций файловой системы и распределение времени выполнения. Аналогичные инструменты есть для XFS и Btrfs.
Среди сторонних выделю:
Linux System Monitor — простая программа с консольным и графическим интерфейсами.
Baobab — это простое приложение, которое может сканировать как отдельные папки (локальные или удалённые), так и целые тома.
QDirStat — кроссплатформенный визуализатор использования дискового пространства с графическим интерфейсом.
Filelight — графический инструмент, который показывает использование пространства в виде диаграмм.
Блочные устройства (диски и тома)
Если на уровне VFS видно, что операций много, следующий шаг — понять, справляется ли сама дисковая подсистема. Здесь уже важны очереди, задержки, глубина I/O и состояние самих устройств.
На схеме в этом слое iostat, blktrace, hdparm, nvme, а также eBPF/BCC-утилиты. От себя добавляю lsblk и iotop, потому что без топологии и быстрого поиска виновника разбор превращается в гадание.
Lsblk показывает все блочные устройства (диски, разделы, LVM тома, RAID) и их иерархию. Это первая команда для ориентира. С неё понятно, какое устройство стоит смотреть в iostat, и где вообще находится нужный том:
lsblk -f
Iostat даёт картину по нагрузке и задержкам на уровне устройств. Лучше смотреть расширенную статистику в динамике — так видно, насколько устройство занято (util), сколько операций проходит (tps), какие скорости чтения и записи, и растут ли задержки. Например, будет раз в 2 секунды выводить загрузку каждого диска и пропускную способность:
iostat -x -z 2
Дальше на схеме стоит biotop, но тут я рекомендую iotop — он проще и почти всегда уже есть в системе. В инциденте он экономит время, потому что сразу показывает процесс, который делает I/O:
sudo iotop
Hdparm читает/записывает низкоуровневые регистры диска, может измерять простые скорости. Например, может проверить скорость чтения:
sudo hdparm -t /dev/sda
Есть и утилита для NVMe-накопителей — nvme. С её помощью можно получить статистику шины PCIe, журналы ошибок и т. д. Запускаем через
sudo nvme smart-log /dev/nvme0n1
Когда нужно понять характер задержек и привязать их к событиям — используем eBPF/BCC. Например, biolatency (строит гистограмму задержек блоковых операций), biosnoop (отслеживает каждую операцию I/O на устройствах, показывая PID процесса и подробности), biotop (показывает процессы или устройства с наибольшим I/O) и другие. Среди сторонних:
Netdata — полнофункциональный мониторинг в реальном времени.
SysUsage — графические отчёты и графики CPU, память, I/O, сеть и диск (через rrdtool).
Monres — лёгкий монитор VPS-ресурсов с уведомлениями, покрывает Disk I/O и сетевые I/O.
Bandwidth Monitor NG — это небольшой и простой консольный монитор пропускной способности сети и дискового ввода-вывода в реальном времени.
tophat — элегантный монитор системных ресурсов для оболочки GNOME.
Сетевой стек
Проблемы в этом стеке почти всегда проявляются тормозами, но причины могут быть в чём угодно — от банальных ошибок на интерфейсе до ретрансляций TCP и кривого DNS.
На схеме в этом слое: ss/netstat, ip, ethtool, nicstat, nstat, lldptool, dropwatch, tcplife, tcpretrans, tcpdump и им подобные. От себя добавляю solisten.
ss — замена netstat, которая показывает все TCP/UDP-соединения и сокеты. Полезна, когда нужно быстро понять, кто держит соединения, кто слушает порт, что висит в SYN-очередях, и не упёрлись ли в лимиты сокетов:
ss -tunap
Для конфигурации сетевых интерфейсов и маршрутизации используем ip (iproute2). С её помощью можно посмотреть статистику по интерфейсам, таблицы маршрутов и др. Например, счётчики на интерфейсе, включая ошибки и дропы на уровне линка:
ip -s link ip route show
Ethtool показывает или настраивает свойства сетевой карты на аппаратном уровне (скорость, режим, ошибки). Аппаратные счётчики ошибок можно посмотреть через:
ethtool -S eth0
Статистику по сетевым интерфейсам выдаёт nicstat. Показывает пакеты в секунду, битрейт, средний размер пакета и прочее. Запуск без параметров выводит сводку по всем интерфейсам.
В свою очередь, nstat читает встроенные SNMP-счётчики ядра для сети. Например, с помощью -z можно посмотреть обнуляемые счётчики пакетов (TX/ RX):
nstat -z
Если нужно увидеть, к какому порту свича подключён сервер и какую информацию он объявляет, то пригодится lldptool. Пример:
sudo lldptool -t -i eth0 -V
Dropwatch пригодится, когда пакеты теряются, но непонятно где. Утилита показывает места, где пакет был отброшен, и помогает отличить дропы драйвера, стека и фильтрации. Например, можно посмотреть, почему не доходят ARP-пакеты:
sudo dropwatch arp
Инструмент, который я добавил, — solisten — показывает, какие процессы слушают порты, и помог��ет поймать моменты переполнения бэклога:
sudo solisten
Если нужно обновление с интервалом, можно указать период (например, 1 секунда):
sudo solisten 1
Дальше смотрим BCC-инструменты для TCP: tcplife (отслеживает TCP-сессии и выводит их продолжительность), tcpretrans (показывает проблемы), tcpdump (сетевой сниффер для CLI) и другие.
Из внешних:
EtherApe — классический графический сетевой монитор с визуализацией узлов и трафика.
Simon — включает сетевую активность и может отображать трафик на панелях.
Linux-Resource-Monitor — отображает сетевой трафик в браузере с реальными графиками.
ntopng — web-мониторинг сетевого трафика.
Планировщик и CPU
Если есть проблемы с планировщиком и конкретно с CPU, то будет расти средняя загрузка, появятся очереди на выполнение, процессы зайдут в состояние R, а также появится неожиданная загрузка на отдельных ядрах. Иногда причина в самом приложении, иногда — в прерываниях, а иногда вовсе — в особенностях железа.
На схеме в этом слое mpstat, pidstat, perf, runqlen, tiptop, turbostat, rdmsr, softirqs, hardirqs, top и atop (также добавил htop / btop). Все утилиты пропишу по подразделам.
Базовая картина по CPU
Mpstat показывает загрузку по каждому ядру. Так видно, распределена ли нагрузка равномерно или одно-два ядра загружены, а остальные простаивают. Отдельно стоит смотреть %usr, %sys, %iowait, %irq, %soft.
mpstat -P ALL 1
Если нужно перейти от уровня ядер к конкретным процессам, то поможет pidstat. Утилита показывает процент использования CPU по задачам в динамике — если нагрузка высокая, здесь же обычно находится процесс, который её генерирует. Запускаем через:
pidstat -u 1
Оперативный мониторинг осуществляем через top / atop или htop / btop. Есть ещё tiptop — расширенная версия top с аппаратными счётчиками на уровне процессов. Тут уже команды писать не буду.
Очереди и планировщик
Если load высокий, но CPU по цифрам не полностью загружен, стоит проверить длину очереди планировщика. Для этого есть BCC-утилита runqlen:
sudo runqlen 1
Она показывает распределение длины run queue — если процессы регулярно накапливаются в очереди, значит, CPU не успевает их обслуживать или есть перекос по ядрам.
Профилирование
Когда понятно, что CPU занят, используется perf. Например, perf top показывает функции, на которые тратится время, а с ключом -g можно увидеть стек вызовов:
perf top -g -p PID
Для аппаратных счётчиков можно использовать:
perf stat -e cycles,instructions,cache-misses -p PID sleep 1
Так видно, сколько инструкций выполняется, сколько тактов тратится и есть ли проблемы с кэшем.
Прерывания
Если нагрузка распределена странно или есть подозрение на interrupt storm, смотрим прерывания через BCC-утилиты. Нижеописанные суммируют время, потраченное на обработку softirq и аппаратных IRQ:
sudo softirqs sudo hardirqs
Аппаратный уровень CPU
Turbostat показывает частоты, C-state, температуру, энергопотребление и топологию CPU:
turbostat 1
Rdmsr из пакета msr-tools позволяет читать модельные регистры CPU. В основном, используется для низкоуровневой диагностики и чтения конкретных аппаратных счётчиков:
sudo rdmsr 0x10A
Используется для низкоуровневой диагностики и чтения конкретных аппаратных счётчиков. Также есть showboost — он показывает состояние Turbo Boost по ядрам и помогает понять, используется ли разгон под нагрузкой:
sudo showboost
Среди сторонних утилит выделю:
Parca Agent — отслеживает трассировки стека в пользовательском и системном пространствах 19 раз в секунду и создаёт профили в формате pprof на основе извлечённых данных;
FlameGraph — инструмент для построения flamegraph из perf, eBPF и других источников.
Scalene — продвинутый профилировщик, который разделяет CPU time, system time и memory pressure.
Память и кэш
Тут у нас всегда типичные проблемы — нехватка памяти, активный сваппинг, фрагментация, битые страницы и неправильные NUMA-распределения.
На схеме в этом слое free, vmstat, numastat, slabtop и sar. Дополнительно добавил memleak и oomkill.
Free показывает используемую свободную память и swap. Для первичной оценки достаточно:
free -h
Vmstat даёт статистику по процессам, памяти, свопу, I/O, и CPU в целом в динамике. Например, можно выставить на 2 секунды:
vmstat 2
Если в столбцах si/so появляются значения, значит, система активно работает со свопом — это почти всегда объясняет просадки по времени ответа.
На многосокетных системах важно понимать, где лежит память. Первая команда тут показывает общее распределение по узлам, вторая — конкретный процесс:
numastat numastat -p PID
Если растут кеши dentry, inode или другие структуры, связанные с ядром, это видно через slabtop (уже писал о нём выше). В свою очередь, sar из sysstat полезен, когда нужно видеть поведение на интервале:
sar -r 1 sar -W 1
* -r — статистика по памяти, -W — по swap. Удобно, когда нужно понять, это разовый всплеск или постоянная тенденция.
Когда память «куда-то уходит», а обычные инструменты не дают виновника, подключаем memleak (BCC):
sudo memleak
Утилита отслеживает выделения памяти и показывает стек вызовов, где она не освобождается. В свою очередь, oomkill показывает, какой процесс уже был убит OOM Killer:
sudo oomkill
Есть ещё два BCC-инструмента. При диагностике RAID-массивов полезен Mdflush — он отслеживает flush-операции в mdraid, а задержки при подкачке страниц из swap показывает Swapin. Дополнительно полезно посмотреть процессы по RSS:
ps aux --sort=-rss
Из внешних утилит неплохие:
memray — профилировщик памяти для Python.
heaptrack — отслеживает все операции по выделению памяти и снабжает эти события трассировкой стека.
Аппаратный уровень
Когда по метрикам всё нормально, проблема оказывается ниже — в частотах, температуре, троттлинге или состоянии шин. Здесь уже смотрим само железо.
На схеме из этого слоя turbostat (был выше), rdmsr (тоже был выше), mpstat/top/perf (для CPU), numastat (для DRAM), smartctl (для дисков), nvme (для NVMe), ipmitool/sensors (для питания/температур — не в схеме).
Привычные top, mpstat, perf показывают потребление ядер, но на аппаратном уровне можно ещё запускать perf stat с событиями (как cycles, instructions, cache-misses). Пример:
perf stat -e cycles,instructions,cache-misses -p PID sleep 1
С помощью этой утилиты видно количество тактов, инструкций и промахов кэша. Если процесс выполняет мало инструкций на большое количество циклов или есть высокий процент промахов кэша — это точно аппаратный профиль.
Через cpupower или старый инструмент cpufrequtils можно проверить текущую политику частот:
cpupower frequency-info
Numastat в этом слое используется уже как индикатор распределения памяти по узлам и каналам DRAM. А состояние накопителей проверяется через:
sudo smartctl -a /dev/sda sudo nvme smart-log /dev/nvme0n1
Если есть доступ к BMC или IPMI, то смотрим через:
ipmitool sensor
Либо через lm-sensors:
sensors
Так можно увидеть температуру CPU, напряжения, состояние питания. Перегрев или просадка напряжения иногда объясняют странное поведение под нагрузкой.
Также отмечу, что для общего снимка системы подходит Dstat — компактный агрегатор CPU, диска, сети и памяти в одном выводе. Он полезен, когда нужно быстро увидеть, что именно проседает, без переключения между несколькими утилитами:
dstat -tcmnd
Среди интересных внешних утилит тут:
Open Hardware Monitor — популярный монитор оборудования,
hwinfo — библиотека для аппаратного тестирования и инструмент командной строки на её основе,
lshw — лёгкий инструмент для получения подробной информации об аппаратной конфигурации компьютера.
На этом и закончим.
Если хотите поизучать труды Грегга — вам сюда, но учтите, на пару часов выпадете из жизни. В комментариях буду рад увидеть, что для мониторинга используете вы, особенно если будет что-то малоизвестное.
© 2026 ООО «МТ ФИНАНС»
