Системный администратор, заходящий на сервер с жалобой пользователя на тормоза, обычно не имеет в руках красивого графического интерфейса. Есть только терминал и набор утилит, которые в умелых руках дают полную картину происходящего. Каждая из них заточена под свою задачу, и понимание различий между ними экономит часы поиска причины проблемы. Пять основных инструментов для разных аспектов нагрузки сервера - htop, iotop, nethogs, iftop и atop - вместе образуют тот самый минимум, без которого работа с Linux в продакшене превращается в гадание на кофейной гуще. Каждый из них показывает свой срез происходящего, и вместе они покрывают практически все сценарии диагностики.
Почему недостаточно классического top и что меняет приход htop в повседневную работу
Команда top существует со времён первой коммерческой Unix и в большинстве дистрибутивов установлена по умолчанию. Она показывает процессы, отсортированные по потреблению CPU, общую загрузку системы, использование памяти и swap. Для быстрого взгляда на состояние машины этого хватает. Проблема в эргономике. Текстовый интерфейс, отсутствие цветовой индикации, неудобное переключение режимов сортировки. Когда нужно работать со списком процессов хоть сколько-нибудь активно, top начинает раздражать.
Htop появился именно как ответ на эти неудобства. Главное визуальное отличие - цветные горизонтальные диаграммы для CPU по ядрам, для памяти и для swap, размещённые в верхней части экрана. С первого взгляда видно, какие ядра загружены, сколько памяти занято, есть ли своп. Дальше идёт список процессов с подсветкой, прокруткой, фильтрацией по имени, возможностью отображения дерева процессов. Особенно полезна возможность немедленно убить процесс без выхода из утилиты и поиска PID отдельной командой.
Установка тривиальная для любого дистрибутива:
# Debian, Ubuntu
sudo apt install htop
# Fedora, RHEL, CentOS
sudo dnf install htop
# Arch Linux
sudo pacman -S htop
Внутри интерфейса работают горячие клавиши, которые имеет смысл выучить наизусть. F5 переключает в режим дерева процессов, F3 открывает поиск, F4 - фильтрацию, F6 выбирает столбец сортировки, F9 убивает выделенный процесс с возможностью выбора сигнала. Клавиши P, M, T быстро сортируют по CPU, памяти и времени работы соответственно.
Для начала диагностики высокой загрузки полезно запустить htop с предварительной сортировкой или фильтром по пользователю:
# Сортировка по CPU при запуске
htop --sort-key PERCENT_CPU
# Только процессы конкретного пользователя
htop -u www-data
Однако htop не показывает дисковых операций per-process в наглядном виде, не показывает сетевой трафик per-process и не имеет исторического логирования. Это инструмент для текущего момента, для быстрой реакции на проблему здесь и сейчас. Для диагностики прошедших инцидентов он бесполезен. Именно поэтому появляются специализированные утилиты для других аспектов нагрузки.
Когда нужен iotop и как он различает реальную нагрузку на диски от кэшированных операций
Если в htop заметна высокая загрузка процессора с большой долей iowait, это сигнал, что процессор простаивает в ожидании дисковых операций. Узнать, какой именно процесс терзает диск, средствами htop невозможно. На сцену выходит iotop. Утилита написана на Python и требует наличия в ядре Linux опций TASK_DELAY_ACCT, CONFIG_TASKSTATS, TASK_IO_ACCOUNTING и CONFIG_VM_EVENT_COUNTERS. В современных дистрибутивах все они включены по умолчанию. Запуск iotop требует root-прав - работать с дисковой статистикой ядра обычный пользователь не может.
sudo apt install iotop
sudo dnf install iotop
Главные столбцы вывода - DISK READ и DISK WRITE, показывающие скорость чтения и записи каждого процесса в килобайтах в секунду. Сверху отображаются Total DISK READ и Total DISK WRITE - суммарная пропускная способность между процессами и кэшем ядра, а также Current DISK READ и Current DISK WRITE - реальный обмен с дисковой подсистемой и физическим железом. Разница между Total и Current важна и часто упускается из виду. Total отражает запросы процессов к ядру, и они могут полностью обслуживаться из page cache без обращения к диску. Current показывает то, что физически пошло на железо.
Для практической работы наиболее полезен такой набор флагов:
sudo iotop -oPa
Здесь -o (only) показывает только процессы, реально выполняющие ввод-вывод, что сильно сокращает шум на экране. -P отображает процессы вместо отдельных потоков. -a (accumulated) накапливает счётчики с момента запуска утилиты, позволяя увидеть, кто за всё время потребил больше всего дисковой пропускной способности.
Если нужно записать снимок дисковой активности в файл для последующего анализа без интерактивного интерфейса, удобна неинтерактивная форма:
sudo iotop -boP -n 60 -d 1 > /tmp/iotop.log
Эта команда снимет 60 показаний с интервалом в одну секунду. Удобно для случаев, когда тормоза кратковременные и нужно поймать их в момент возникновения автоматическим скриптом.
Типичный сценарий применения. Сервер начал тормозить, htop показывает iowait 50% при простаивающих процессах. Запуск iotop сразу выводит виновника - например, процесс резервного копирования, забывший про nice-приоритет, забивает диски на сотни мегабайт в секунду. Решение - либо снизить приоритет ввода-вывода, либо просто перенос задания на более спокойное время. Снижение приоритета делается командой ionice:
sudo ionice -c 3 -p PID
Класс 3 (idle) означает, что процесс получит дисковое время только тогда, когда другим оно не нужно.
Чем nethogs отличается от iftop и почему оба нужны для разных сценариев сетевой диагностики
С сетевой нагрузкой ситуация интереснее. Есть две принципиально разные задачи. Первая - узнать, какой процесс генерирует или потребляет сетевой трафик. Вторая - увидеть, какие соединения активны, между какими IP-адресами и портами идёт обмен и с какой пропускной способностью. Эти задачи решаются разными утилитами. Nethogs специализируется на первой, iftop - на второй.
Nethogs работает через парсинг /proc и привязывает сетевой трафик к конкретным процессам:
sudo apt install nethogs
# Анализ конкретного интерфейса
sudo nethogs eth0
# Все интерфейсы с интервалом обновления 2 секунды
sudo nethogs -d 2
Внутри интерфейса работают горячие клавиши - r сортирует по общему трафику, s по отправленному, q закрывает утилиту, m переключает единицы измерения между КБ/с, КБ, Б и МБ.
Полезный сценарий применения - выявление утечки трафика. Сервер расходует пропускную способность канала, лимит провайдера приближается, причина непонятна. Nethogs показывает, какой процесс потребляет трафик. Часто оказывается, что это забытый rsync, продолжающий синхронизацию после изменения конфигурации, или клиентский скрипт, попавший в бесконечный цикл запросов к API внешнего сервиса. Без nethogs пришлось бы вручную смотреть netstat или ss, сопоставлять PID с процессами и считать трафик через iptables-счётчики, что значительно дольше.
Iftop устроен иначе. Он не показывает процессы вообще. Зато даёт детальную картину сетевых соединений - кто с кем общается, в каком направлении течёт трафик, с какой скоростью.
sudo apt install iftop
# Базовый запуск
sudo iftop -i eth0
# С отображением портов и без DNS-резолвинга
sudo iftop -i eth0 -P -n
Ключ -P включает отображение портов, -n отключает разрешение DNS-имён. Это важно при высокой нагрузке - сам DNS под нагрузкой может тормозить и искажать картину. На экране появляются три графы скоростей за последние 2, 10 и 40 секунд, что позволяет видеть как мгновенные значения, так и тренды.
Внутри iftop работает набор полезных горячих клавиш:
p - переключение отображения портов
n - переключение DNS-резолвинга
N - разрешение портов в имена сервисов
t - переключение режима отображения сторон
T - между накопленным и текущим трафиком
s - фильтр по адресу источника
d - фильтр по адресу назначения
Для анализа всех интерфейсов сразу полезно использовать виртуальный any:
sudo iftop -i any -P -n
Почему iftop становится первой линией обороны при подозрении на DDoS
При DDoS-атаке сервер отказывает, нормальные пользователи не могут подключиться, в логах десятки тысяч записей в секунду. Nethogs в такой обстановке практически бесполезен - он покажет, что весь трафик висит на процессе nginx или apache, что уже и так очевидно. Iftop, напротив, в режиме отображения портов и без DNS-резолвинга показывает реальную картину - десятки или сотни IP-адресов, бомбардирующих сервер запросами на 80-й или 443-й порт.
С этой картиной уже можно работать. Анализ распределения трафика по адресам подсказывает, имеем ли мы дело с распределённой атакой или с действиями нескольких узлов. Если видны характерные паттерны, например все источники из одного облачного провайдера или одной географической зоны, это упрощает построение блокирующих правил. После идентификации диапазонов можно применить временную блокировку:
# Блокировка одиночного адреса
sudo iptables -A INPUT -s 192.0.2.10 -j DROP
# Блокировка целой подсети
sudo iptables -A INPUT -s 192.0.2.0/24 -j DROP
Для автоматизации защиты на основе паттернов нагрузки удобен fail2ban или специализированные инструменты вроде CrowdSec.
Что делает atop особенным и почему именно эта утилита заслуживает отдельного места в арсенале
Все предыдущие инструменты показывают текущее состояние. Они полезны, когда проблема происходит прямо сейчас, и администратор сидит за консолью. Но что делать, если сервер тормозил вчера ночью, восстановился к утру, и теперь нужно понять, что произошло? Htop, iotop, nethogs, iftop - бессильны, они работают только в реальном времени. Здесь на сцену выходит atop, единственный инструмент из списка, обладающий полноценным историческим логированием.
Установка и активация фонового сервиса логирования:
# Debian, Ubuntu
sudo apt install atop
sudo systemctl enable --now atop
# Fedora, RHEL, CentOS
sudo dnf install atop
sudo systemctl enable --now atop
После запуска демона atop начинает накапливать данные в сжатом бинарном формате в каталоге /var/log/atop/. Файлы именуются по дате, например atop_20260427. По умолчанию интервал записи 10 минут, срок хранения 28 дней. Параметры логирования настраиваются в файле конфигурации /etc/default/atop в Debian-системах или /etc/sysconfig/atop в RHEL-производных:
LOGINTERVAL=600
LOGGENERATIONS=28
LOGOPTS=""
LOGPATH=/var/log/atop
LOGINTERVAL задаёт интервал в секундах. Для критичных продакшен-серверов имеет смысл уменьшить его до 60 секунд для более детальной картины инцидентов. LOGGENERATIONS определяет срок хранения логов в днях.
Когда настало время разобраться, что было ночью, выполняется команда чтения лога:
# Просмотр всего лога за дату
atop -r /var/log/atop/atop_20260427
# Переход к конкретному времени
atop -r /var/log/atop/atop_20260427 -b 03:15
Внутри утилита переходит в режим навигации по времени. Полезные горячие клавиши:
t - переход вперёд на один интервал записи
T - переход назад на один интервал
b - переход к указанному времени
c - сортировка по CPU
m - сортировка по памяти
d - сортировка по диску
n - сортировка по сети
A - автоматический режим (по самому загруженному ресурсу)
g - возврат к виду по умолчанию
v - детализация процессов с UID, PID, GID
Важнейшая черта atop - использование цвета для индикации критических уровней нагрузки. CPU подсвечивается красным при 90% и выше, диски при 70% busy, сетевые интерфейсы при 90%, память при 90% занятого. Эти пороги подобраны на основе понимания, что разная нагрузка по-разному ощущается приложениями. Диск, занятый на 80%, уже создаёт заметные тормоза для приложений, тогда как CPU при 80% ещё работает приемлемо. Поэтому atop сигнализирует о дисковой нагрузке раньше.
Для аналитики без интерактивного режима в комплекте идёт atopsar - утилита, генерирующая текстовые отчёты из бинарных логов:
# Отчёт по CPU за день
atopsar -c -r /var/log/atop/atop_20260427
# По памяти
atopsar -m -r /var/log/atop/atop_20260427
# По диску
atopsar -d -r /var/log/atop/atop_20260427
# По сети
atopsar -n -r /var/log/atop/atop_20260427
Это идеальный инструмент для построения графиков, экспорта в системы вроде Grafana или просто для чтения отчёта в почтовой рассылке утренней проверки серверов.
Как все пять инструментов работают вместе в типовых сценариях диагностики
Реальная диагностика проблемы редко обходится одним инструментом. Чаще всего администратор использует их последовательно, переходя от общего взгляда к частному. Типичный workflow выглядит примерно так. Поступает жалоба на тормоза. Первое - htop для общего понимания. Высокий CPU с указанием на конкретный процесс - htop с сортировкой по CPU. Высокий iowait - запускается iotop с фильтром только активных процессов. Сеть тормозит - сначала iftop для понимания общей картины, потом nethogs для привязки трафика к процессам. Проблема была вчера ночью - atop -r открывает лог за нужную дату.
Удобно держать на серверах небольшой shell-скрипт быстрой первичной диагностики:
#!/bin/bash
# quick-check.sh
echo "=== System load ==="
uptime
echo "=== Memory ==="
free -h
echo "=== Disk space ==="
df -h | grep -v tmpfs
echo "=== Top 5 CPU processes ==="
ps aux --sort=-%cpu | head -6
echo "=== Top 5 memory processes ==="
ps aux --sort=-%mem | head -6
echo "=== Active connections ==="
ss -s
Такой скрипт за пять секунд даёт первое представление о состоянии сервера, после чего уже принимается решение, какой из специализированных инструментов запустить дальше.
Для постоянного мониторинга стоит держать atop включённым как сервис на всех серверах. Iotop, nethogs и iftop в качестве постоянно запущенных не имеют большого смысла. Они нужны точечно, в момент диагностики конкретной проблемы, и установлены должны быть на каждом сервере в составе базового пакета. Все три устанавливаются стандартными командами через пакетные менеджеры, и забывать об их установке при подготовке нового сервера - частая ошибка, которая приводит к необходимости устанавливать инструменты в самый неподходящий момент, когда сервер уже горит.
Какие альтернативы существуют и где они могут пригодиться помимо описанной пятёрки
Список не исчерпывает всех существующих инструментов мониторинга. Glances - универсальный кросс-платформенный монитор, написанный на Python, объединяющий многие функции отдельных утилит в одном экране. Nmon - мощный инструмент с возможностью сохранения данных в CSV для дальнейшего анализа. Dstat и его преемник pcp-dstat - комбинированный вывод показателей CPU, памяти, диска и сети в одной строке, удобный для отслеживания корреляций.
В корпоративной инфраструктуре пятёрка локальных утилит дополняется системами централизованного мониторинга - Zabbix, Prometheus с Grafana, Datadog. Они дают долгосрочную статистику, корреляцию между серверами, оповещения. Но они не заменяют локальные инструменты. Когда сервер начинает тормозить и нужно за две минуты найти виновника, никакая централизованная система не покажет деталей лучше, чем atop в интерактивном режиме на самой машине. Локальные утилиты остаются основой быстрой реакции, тогда как централизованные системы работают как стратегический мониторинг и долгосрочная аналитика.
Окончательный совет для тех, кто только начинает работать с серверной инфраструктурой Linux. Запомнить пять команд - htop, iotop, nethogs, iftop, atop - выучить их основные горячие клавиши и установить на каждом обслуживаемом сервере. Это минимальный джентльменский набор, без которого профессиональная работа невозможна. Все остальные инструменты добавляются по мере роста задач, но эти пять остаются неизменным фундаментом диагностики. Atop в этой пятёрке стоит особняком как единственный, способный рассказать о прошлом, что часто оказывается важнее любой картинки настоящего.
Канал сайта в Telegram
Канал сайта на YouTube