Полезные консольные утилиты Linux для системного администратора

Сильный администратор не тот, кто помнит сотни ключей наизусть, а тот, кто мгновенно подбирает инструмент под задачу. В Linux это особенно заметно: одна утилита показывает нагрузку, другая — логи, третья — сетевые соединения, и именно связка команд даёт полную картину без паники и лишних движений.

Здесь собран набор утилит, которые реально выручают каждый день: диагностика, мониторинг, сеть, диски, процессы, обслуживание серверов. Материал заточен под практику и подойдёт как новичку, который только начинает разбираться с консолью, так и администратору, желающему систематизировать свой арсенал.

Зачем вообще знать консольные утилиты Linux

Графический интерфейс на сервере — редкость. В боевой эксплуатации важнее быстро ответить на конкретные вопросы:

• почему машина тормозит;
• какой процесс отъедает память или процессор;
• сколько осталось свободного места;
• кто висит на порту;
• где спряталась ошибка в логах;
• как идут пакеты и не обрывается ли маршрут;
• как перезапустить службу без лишних телодвижений.

Если всё это делать через терминал, вы экономите время и получаете точную, неискажённую картину. На серверах под Linux это не «фишка», а стандартный рабочий сценарий. Когда я только начинал, то часто пытался искать проблемы через веб-панели или файловые менеджеры — и почти всегда проигрывал в скорости. Консоль даёт прямой доступ к состоянию системы, и чем раньше вы к ней привыкнете, тем быстрее станете самостоятельным администратором.

Базовый набор утилит, без которого сложно обойтись

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

Мониторинг нагрузки: что смотреть в первую очередь

top и htop

top — самый быстрый способ увидеть, что происходит на сервере прямо сейчас. Он выводит загрузку процессора, памяти, список процессов и их аппетиты. Я часто запускаю его первым делом при любых подозрениях на тормоза: взгляд на load average и верхние строки процессов даёт мгновенный срез.

htop удобнее для ежедневной работы: цветной интерфейс, сортировка по колонкам, возможность убить процесс, не набирая kill, и наглядные индикаторы по ядрам CPU. Если есть выбор, я ставлю htop везде, где можно. Но помните: на минимальных установках его может не быть, поэтому базовый top тоже нужно знать.

Полезные наблюдения из практики:

• высокий %CPU у процесса не всегда означает проблему — возможно, он просто активно работает;
• если CPU почти свободен, а сервер тормозит, первым делом смотрите диск и память;
• растущий load average не обязательно указывает на перегрузку процессора — часто причина в ожидании ввода-вывода (I/O wait). Новички нередко путают эти показатели и начинают оптимизировать не то.

free

Команда free -h помогает быстро понять, хватает ли памяти. В Linux часть RAM может быть занята кешем — это абсолютно нормально. Ошибка новичка — паниковать, увидев, что «почти вся память занята». На самом деле ядро использует свободную память для кеширования файлов, чтобы ускорить работу, и при необходимости отдаст её процессам.

Смотрите не только на used, но и на:

• available — реальный запас, который система может выделить без свопинга;
• swap — если он активно используется, системе действительно не хватает оперативной памяти;
• резкий рост потребления при обычной нагрузке — сигнал к поиску утечки или внезапно расплодившихся процессов.

vmstat

vmstat полезен, когда нужно быстро оценить картину целиком: процессор, память, swap, блокировки, ввод-вывод. Особенно удобно запускать его с интервалом, например vmstat 2 — каждые две секунды. Так вы видите динамику, а не мгновенный снимок.

Применяю его в трёх типичных ситуациях:

• жалобы на тормоза — чтобы понять, куда копать дальше;
• перед перезапуском сервиса — для фиксации исходного состояния;
• при поиске узкого места в производительности, когда неясно, процессор, память или диск виноваты.

iostat

Если система «висит», а CPU не забит, почти наверняка проблема в диске. iostat показывает активность устройств хранения, загрузку и время ожидания. Это часть пакета sysstat, который я рекомендую ставить сразу после базовой настройки сервера.

На что обращать внимание:

• высокая задержка записи и чтения (await);
• постоянная высокая нагрузка на диск (%util близка к 100%);
• отставание по I/O при одновременном росте очередей (avgqu-sz).

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

Работа с процессами: найти, понять, остановить

ps

ps даёт снимок процессов в текущий момент. Это удобно, когда нужно найти PID, проверить аргументы запуска или узнать, под каким пользователем работает служба. В отличие от top, он не обновляется, зато позволяет строить сложные фильтры через grep.

Частые сценарии из моей практики:

• поиск процесса по имени: ps aux | grep nginx;
• проверка родительского процесса (PPID), чтобы понять, кто запустил демона;
• диагностика зависшего сервиса — смотрю, висит ли он вообще, и с какими аргументами был запущен.

kill и pkill

Эти команды нужны, когда процесс надо завершить. kill работает по PID, pkill — по имени или части имени. Я предпочитаю сначала pkill -f для поиска по полной командной строке, но только если уверен в шаблоне.

Важно помнить:

• сначала пробуйте мягкую остановку: kill PID (SIGTERM), и только если не помогает — kill -9 PID (SIGKILL);
• не убивайте процесс без понимания, что именно он делает — можно оставить после себя разорванные соединения или повреждённые данные;
• после завершения обязательно проверьте логи и причину зависания, иначе проблема повторится.

nice и renice

Если задача не срочная, можно уменьшить её приоритет. Это полезно для фоновых операций: резервного копирования, массовой обработки файлов, тяжёлых скриптов. Например, я часто запускаю бэкап с nice -n 19, чтобы он не отнимал процессорное время у боевых сервисов.

Практический смысл:

• не дать бэкапу «задушить» веб-сервер или базу данных;
• временно снизить влияние долгой операции на пользователей, пока не найдёте постоянное решение.

Диски и файловые системы: где пропало место

df

df -h — первая команда, когда внезапно закончилось место. Она показывает заполнение файловых систем, а не отдельных каталогов. Я всегда начинаю с неё, потому что часто вижу, как новички сразу лезут в du и теряются, не понимая, какой раздел переполнен.

Проверьте:

• какой раздел переполнен — /, /var, /home или отдельный mount point;
• не вырос ли /var/log — логи могут забить всё за ночь;
• не закончился ли /tmp — туда пишутся временные файлы;
• не забит ли раздел с базами данных или почтовыми ящиками.

du

du помогает найти, что именно заняло место внутри каталога. Обычно я использую du -sh * | sort -h в корне подозрительного раздела, чтобы быстро увидеть самые тяжёлые директории. Это гораздо быстрее, чем гадать.

Типовой сценарий, с которым сталкивался не раз:

• огромный лог-файл, который забыли ротировать;
• кеш приложения, разросшийся до гигабайтов;
• старые архивы или дампы, о которых все забыли;
• забытые временные файлы сборки.

find

find — одна из самых полезных утилит для поиска файлов. С её помощью можно искать по имени, размеру, времени изменения и другим признакам. Я часто комбинирую её с -exec для автоматизации чистки.

Частые задачи:

• найти большие файлы: find / -type f -size +100M;
• удалить старые логи: find /var/log -name "*.log" -mtime +30 -delete;
• проверить, где лежат конфиги: find /etc -name "*.conf";
• собрать список файлов за определённый период для аудита.

lsof

lsof показывает открытые файлы и процессы, которые их держат. Это особенно полезно, когда файл удалили, а место на диске не освободилось (потому что процесс всё ещё держит дескриптор), или когда непонятно, кто занял порт. Типичный пример: вы удалили огромный лог, а df показывает, что место не вернулось. lsof | grep deleted быстро находит виновника.

Сеть: проверка портов, маршрута и соединений

ss

ss — современная и быстрая замена старым инструментам вроде netstat. С её помощью удобно проверить, какие порты слушаются и какие соединения активны. Я использую ss -tlnp для просмотра слушающих TCP-портов с именами процессов — это первое, что делаю, когда не стартует веб-сервер или база данных.

Сценарии применения:

• проверить, запущен ли веб-сервер и на каком порту;
• убедиться, что база данных слушает нужный интерфейс (не только localhost);
• посмотреть активные подключения к сервису;
• найти лишний открытый сервис, который забыли отключить.

ping

Простейшая, но по-прежнему полезная проверка доступности хоста. Если ping не проходит, это не всегда значит, что узел «лежит» — иногда ICMP просто блокируется на firewall. Поэтому я всегда дополняю его проверкой порта через ss или curl.

traceroute и mtr

Эти утилиты помогают понять, где теряются пакеты и на каком участке сети появляется задержка. mtr особенно хорош: он объединяет ping и traceroute в реальном времени, показывая потери на каждом хопе.

Используйте их, если:

• сайт открывается медленно, но сервер локально отзывается нормально;
• есть подозрение на проблемы у провайдера;
• соединение обрывается на определённом участке маршрута.

ip

Современный администратор должен уверенно работать с ip. Эта утилита заменяет старый набор команд (ifconfig, route, arp) и позволяет смотреть интерфейсы, маршруты, адреса и таблицы соседей. Я рекомендую сразу привыкать к ней, а не цепляться за устаревшие инструменты.

Минимум, который стоит знать:

• просмотр IP-адресов: ip addr show;
• проверка маршрута: ip route show;
• включение и отключение интерфейсов: ip link set eth0 up/down;
• анализ состояния сети и соседей: ip neigh.

curl

curl — незаменимая утилита для проверки HTTP/HTTPS, API и доступности сервисов. Ею удобно тестировать ответы, заголовки, коды состояния и содержимое. Я часто использую curl -I для проверки заголовков или curl -v для детального вывода, когда нужно понять, где спотыкается соединение.

Практика:

• проверить, отвечает ли сайт: curl -o /dev/null -s -w "%{http_code}\n" http://example.com;
• посмотреть редиректы и их цепочку;
• протестировать API без браузера, передавая нужные заголовки и данные;
• проверить доступ к локальному сервису, который не слушает внешний интерфейс.

Логи и диагностика: где искать причину проблемы

journalctl

На системах с systemd это один из главных инструментов. Через него смотрят логи сервисов, загрузки, ошибок и событий за нужный промежуток времени. Я предпочитаю journalctl -u nginx --since today — так я вижу только то, что относится к конкретному сервису, и не тону в общем потоке.

Полезно для:

• анализа падения службы: что было непосредственно перед остановкой;
• поиска ошибок запуска, когда сервис не стартует после изменения конфига;
• проверки событий после перезагрузки: journalctl -b;
• фильтрации по сервису и времени: journalctl -u sshd --since "1 hour ago".

dmesg

dmesg показывает сообщения ядра. Это важно, когда проблема связана с дисками, драйверами, памятью или оборудованием. Я всегда заглядываю в dmesg, если сервер не видит новый диск или внезапно начались ошибки ввода-вывода.

Обратите внимание на:

• ошибки устройств (I/O error, sector read errors);
• проблемы с подключением диска (например, таймауты SATA);
• сбои драйверов (часто после обновления ядра);
• признаки нехватки ресурсов (OOM-killer).

grep и less

Это не просто «поисковики», а базовые помощники администратора. grep позволяет находить строки по шаблону, а less удобно читать большие логи постранично. Я часто строю цепочки: journalctl | grep ERROR | less — так я получаю только ошибки и листаю их в удобном режиме.

Именно связка journalctl | grep или less /var/log/syslog часто помогает быстрее всего добраться до сути. Не пренебрегайте регулярными выражениями в grep — они экономят кучу времени.

Управление службами и доступом

systemctl

Если на сервере используется systemd, без systemctl не обойтись. Через него запускают, останавливают, перезапускают и проверяют статус сервисов. Я всегда после правки конфига делаю systemctl restart nginx и сразу systemctl status nginx, чтобы убедиться, что сервис поднялся без ошибок.

Используется для:

• перезапуска nginx, Apache, базы данных;
• включения автозапуска: systemctl enable nginx;
• проверки статуса после изменений;
• диагностики отказа службы: systemctl status nginx покажет последние строки лога и код выхода.

sudo

Одна из главных привычек хорошего администратора — работать с повышенными правами только там, где это действительно нужно. sudo помогает безопасно выполнять административные команды, не сидя постоянно под root. Я настраиваю sudo так, чтобы логировать все действия, и потом можно было восстановить, кто и что делал.

ssh

Через ssh администратор подключается к удалённым серверам, выполняет команды, переносит файлы и устраняет проблемы на расстоянии. Это базовый инструмент для любой серверной работы. Я рекомендую сразу настроить ключи вместо паролей и использовать ssh-agent для удобства.

Полезные утилиты для глубокого анализа

strace

Если программа запускается, но ведёт себя странно, strace показывает системные вызовы процесса. Это очень полезно при отладке зависаний, ошибок доступа, проблем с файлами и библиотеками. Я часто использую strace -p PID, чтобы присоединиться к уже работающему процессу и посмотреть, на каком вызове он застрял.

Когда использовать:

• процесс не стартует без явной ошибки — strace покажет, какого файла или библиотеки не хватает;
• приложение зависает на одном месте — видно, ждёт ли оно ввода-вывода, блокировки или чего-то ещё;
• непонятно, к какому файлу или сокету оно обращается — strace выведет все открываемые дескрипторы.

tcpdump

tcpdump нужен для анализа сетевого трафика в консоли. Это мощный инструмент, когда обычной проверки порта уже недостаточно. Я использую его, чтобы убедиться, что пакеты действительно уходят с сервера и приходят на него, а не теряются где-то по пути.

Подходит для:

• поиска проблем между хостами: видно, кто кому шлёт запросы и приходят ли ответы;
• проверки, идут ли пакеты вообще (например, при настройке VPN);
• анализа неожиданного трафика (подозрительная активность);
• диагностики сложных сетевых ошибок на уровне протокола.

Какой набор утилит учить в первую очередь

Если вы только входите в Linux-администрирование, не распыляйтесь. Освойте сначала этот минимум. Именно с него я начинал сам и рекомендую всем новичкам — он покрывает 80% типовых инцидентов.

1. ssh
2. systemctl
3. journalctl
4. top или htop
5. free
6. df
7. du
8. ps
9. ss
10. curl
11. grep
12. find
13. ip

Этого уже достаточно, чтобы закрывать большую часть типовых инцидентов на сервере. Остальное будет добираться по мере необходимости.

Типовые ошибки новичков

За годы работы я видел одни и те же грабли, на которые наступают почти все начинающие администраторы. Вот самые частые:

• Путают нехватку RAM с использованием кеша. Видят в free мало свободной памяти и начинают паниковать, хотя available ещё полно.
• Смотрят только на CPU и забывают про диск. Тормоза часто вызваны медленным вводом-выводом, а не процессором.
• Проверяют ping и считают, что этого достаточно для диагностики сети. ICMP может быть заблокирован, а сервис на порту 443 при этом отлично работает.
• Убивают процесс, не понимая, почему он завис. Симптом сняли, а причина осталась — через час всё повторится.
• Ищут причину только в приложении, игнорируя логи системы. А там может быть OOM-killer, который прибил процесс.
• Работают от root там, где хватило бы sudo. Это опасно и затрудняет аудит.
• Не проверяют, какой именно раздел заполнен, и чистят «не то». Например, удаляют файлы из /home, когда переполнен /var.

Практический алгоритм быстрой диагностики сервера

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

1. Проверьте доступность узла через ssh или локальный вход. Если не пускает, проблема может быть на уровне сети или загрузки.
2. Посмотрите нагрузку через top или htop. Оцените загрузку CPU, load average и самые прожорливые процессы.
3. Оцените память через free -h. Обратите внимание на available и swap.
4. Проверьте диск через df -h. Убедитесь, что нет переполненных разделов.
5. Посмотрите активные процессы через ps. Возможно, какой-то процесс порождает множество копий.
6. Проверьте сеть через ss. Удостоверьтесь, что нужные порты слушаются.
7. Загляните в логи через journalctl. Ищите ошибки по времени возникновения проблемы.
8. Если есть признаки проблем с железом или ядром — откройте dmesg.
9. При сложной ошибке используйте strace или tcpdump для точечного анализа.

Чек-лист администратора перед выездом на инцидент

Когда случается серьёзный сбой, важно не забыть базовые вещи. Я держу в голове такой чек-лист, и он не раз спасал от лишних действий.

• Доступ по ssh работает (или есть консоль).
• Есть права через sudo.
• Проверены CPU, RAM и swap.
• Проверено свободное место на всех разделах.
• Посмотрены логи сервиса и системы.
• Проверены порты и соединения.
• Сохранен контекст проблемы: время, ошибка, последние изменения.
• Понятно, что менялось перед сбоем (кто-то правил конфиг, обновлял пакеты, перезагружал сервер).

FAQ

Какие консольные утилиты Linux самые важные для системного администратора?

В первую очередь стоит знать ssh, systemctl, journalctl, top, htop, free, df, du, ps, ss, grep, find и ip. Это минимальный джентльменский набор, который закрывает большинство повседневных задач.

Что использовать, если сервер тормозит, но CPU не загружен?

Сначала проверьте free, vmstat, iostat, затем логи и дисковую подсистему. Часто проблема не в процессоре, а в памяти или I/O. Например, база данных может упираться в медленный диск, и процессор будет простаивать в ожидании данных.

Чем htop лучше top?

htop удобнее визуально: цвета, сортировка по клику, интерактивная работа с процессами (можно убить процесс, не набирая команду). top при этом есть почти везде и подходит для быстрого доступа без установки дополнительных пакетов. Я обычно ставлю htop на все свои серверы, но в скриптах и при удалённой диагностике через узкий канал иногда проще использовать top.

Как быстро найти, кто занял место на диске?

Сначала df -h, чтобы увидеть переполненный раздел, потом du -sh * | sort -h в корне этого раздела для поиска тяжёлых каталогов и find для точечных проверок файлов. Например, find /var -type f -size +100M покажет самые крупные файлы.

Какая утилита помогает смотреть логи сервисов в systemd?

Для этого используется journalctl. С её помощью можно фильтровать по сервису, времени, уровню ошибок и даже следить за логами в реальном времени (journalctl -u nginx -f).

Вывод

Полезные консольные утилиты Linux — это не просто список команд, а рабочий набор для ежедневной диагностики и обслуживания серверов. Чем увереннее вы владеете базовыми инструментами, тем быстрее находите причину проблемы и тем меньше времени тратите на хаотичный поиск.

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