Как диагностировать Linux-сервер по слоям

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

Рабочая диагностика идёт от симптома к слою системы. Сначала фиксируется точное время и подтверждается проблема. Затем проверяется путь запроса: служба, процессы, память, диск, сеть и журналы. На каждом шаге нужен вопрос, а не желание «посмотреть всё».

Зафиксируйте симптом до перезапуска

Запишите, что именно не работает: страница не открывается, открывается медленно, загрузка файла падает или SSH разрывается. Укажите адрес, действие пользователя, текст ошибки и время с часовым поясом.

Следующий небольшой снимок выполняется от обычного пользователя и ничего не меняет. Он показывает время сервера, длительность работы, среднюю нагрузку, неисправные systemd-службы, память и заполнение файловых систем:

date --iso-8601=seconds
uptime
systemctl --failed --no-pager
free -h
df -hT

Сохраните вывод в заметку инцидента. Средняя нагрузка из uptime показывает число задач, готовых выполняться или ожидающих непрерываемый ввод-вывод, за 1, 5 и 15 минут. Она не равна проценту CPU, поэтому высокое значение нужно сопоставить с процессами и диском.

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

Отделите внешний путь от самого приложения

Если проблема видна по домену, сравните внешний запрос с обращением к приложению на самом сервере. Сначала проверьте, какой адрес получает Linux, затем запросите публичный URL с ограничением времени:

getent ahosts example.com
curl -I --max-time 10 https://example.com/

Замените example.com своим доменом. getent должен вернуть ожидаемый IP-адрес, а curl — строку состояния HTTP и заголовки. Ошибка разрешения имени направляет к диагностике DNS в Linux; успешное разрешение с тайм-аутом требует проверки маршрута, firewall и слушающих портов.

Если Nginx передаёт запрос приложению на 127.0.0.1:3000, обратитесь к нему в обход внешнего DNS и TLS:

curl -I --max-time 5 http://127.0.0.1:3000/

Быстрый локальный ответ при медленном публичном запросе переносит внимание на Nginx, TLS, сеть или внешний путь. Если локальный запрос тоже медленный, ищите причину в приложении и его зависимостях. Порт и протокол должны соответствовать вашей конфигурации.

Проверьте, запущена ли нужная служба

Для systemd-службы начните со статуса и последних сообщений. В примере используется Nginx; подставьте точное имя своего сервиса:

systemctl status nginx --no-pager
sudo journalctl -u nginx --since "30 minutes ago" --no-pager

Статус показывает основной процесс, время запуска и последнюю ошибку. В журнале ищите события рядом с записанным временем, а не только последнюю строку. Не запускайте службу снова до чтения ошибки: повторная попытка может затереть важный контекст или занять уже используемый порт.

Убедитесь, что ожидаемый процесс слушает правильный адрес и порт. Ключи -ltnp означают слушающие TCP-сокеты, числовые адреса и, при наличии прав, имена процессов:

sudo ss -ltnp

Адрес 127.0.0.1:3000 доступен только с самого сервера, 0.0.0.0:80 — на всех IPv4-интерфейсах. Отсутствующий порт объясняет отказ соединения; занятый неожиданным процессом порт объясняет ошибку запуска службы.

Найдите процесс, который потребляет ресурс

Если uptime показывает рост нагрузки, посмотрите процессы по использованию CPU и памяти. Команда ниже выводит идентификатор процесса, пользователя, состояние, доли ресурсов, время работы и команду:

ps -eo pid,user,state,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 20
ps -eo pid,user,state,%cpu,%mem,etime,cmd --sort=-%mem | head -n 20

Один краткий всплеск CPU не доказывает проблему. Сравните несколько наблюдений и время начала процесса. Состояние R означает выполнение или готовность к нему, S — обычное ожидание, а D — непрерываемое ожидание, часто связанное с диском или сетевым хранилищем.

Перед завершением процесса выясните его владельца и роль. Если им управляет systemd, используйте systemctl и прочитайте журнал. Сигнал SIGTERM даёт программе возможность корректно закрыть файлы; SIGKILL оставляйте для процесса, который не реагирует и для которого оценены последствия. Подробный разбор есть в статье о процессах Linux.

Проверьте память и сообщения OOM

free -h показывает физическую память и swap. Ориентируйтесь на available, а не на небольшой столбец free: Linux использует свободную память под кеш и может освободить его при необходимости.

Если процесс внезапно исчез или служба перезапустилась, проверьте сообщения ядра об OOM — механизме, который завершает процесс при исчерпании памяти:

sudo journalctl -k --since "2 hours ago" --no-pager | grep -Ei 'out of memory|oom|killed process'
systemctl show nginx -p NRestarts -p ActiveEnterTimestamp

Первая команда фильтрует журнал ядра. Вторая показывает число перезапусков и момент последнего перехода Nginx в активное состояние; для приложения замените имя службы. Найденная запись Killed process вместе со временем сбоя — сильное подтверждение нехватки памяти, но затем нужно определить, почему потребление выросло.

Размер кеша, утечка в приложении и слишком большое число рабочих процессов требуют разных исправлений. Временное добавление swap может дать запас, но не заменяет поиск причины; последовательность разобрана в руководстве о RAM, swap и OOM.

Разделите нехватку места и нехватку inode

Файловая система может перестать создавать файлы при наличии свободных гигабайт, если исчерпаны inode — записи с метаданными файлов. Проверьте оба ограничения:

df -hT
df -ih

В первом выводе смотрите столбец использования пространства, во втором — IUse%. Значение около 100% на нужной точке монтирования объясняет ошибки No space left on device. Не удаляйте первый крупный каталог: сначала выясните его назначение и политику хранения.

Чтобы найти направление роста в /var, ограничьте поиск одной файловой системой. Команда суммирует размер каталогов первого уровня и не переходит на отдельно смонтированные диски:

sudo du -xhd1 /var 2>/dev/null | sort -h

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

Проверьте сеть только после формулировки вопроса

При сетевой ошибке сначала посмотрите адреса и маршрут по умолчанию. Эти команды ничего не меняют:

ip -brief address
ip route
ip route get 1.1.1.1

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

Для конкретного TCP-порта используйте приложение-клиент либо nc с ограничением времени. Следующий пример проверяет установление соединения с HTTPS-портом, но не сертификат и не HTTP-ответ:

nc -vz -w 5 example.com 443

Успешное соединение означает, что TCP-рукопожатие состоялось. Тайм-аут может возникнуть на маршруте или в firewall, а Connection refused обычно означает доступный узел без слушающей службы на этом порту. Не делайте вывод о DNS, если проверяли только IP-адрес.

Свяжите события по времени

Журнал полезен, когда запрос ограничен интервалом сбоя. Следующая команда показывает предупреждения и ошибки системы между двумя моментами; замените даты своим окном:

sudo journalctl --since "2026-09-05 14:20:00" --until "2026-09-05 14:35:00" -p warning --no-pager

Уровень warning включает более серьёзные сообщения, но приложение может записать важную причину как info. Если общий запрос ничего не дал, повторите его по имени нужной службы без фильтра приоритета. Учитывайте часовой пояс сервера и внешней системы наблюдения.

Сравните начало симптома с обновлением пакета, deploy, перезапуском, ростом очереди или сообщением ядра. Совпадение по времени формирует гипотезу, а не окончательный вывод.

Меняйте одну причину и повторяйте измерение

Перед исправлением сформулируйте проверяемое утверждение: «локальный порт не слушается, потому что служба не запустилась после ошибки конфигурации». Затем проверьте конфигурацию, исправьте одну ошибку и повторите systemctl status, ss и тот же curl.

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

После восстановления запишите:

1. какой симптом и в какое время наблюдался;
2. какие данные подтвердили причину;
3. какое изменение выполнено и как его откатить;
4. какой тест подтвердил результат;
5. какое наблюдение предупредит повторение.

Для постоянного контроля используйте измеримые пороги и проверку снаружи сервера. Начальная схема описана в руководстве по мониторингу VPS, а работа с журналом — в статье о journalctl.

Первоисточники

• proc_loadavg(5) — смысл средней нагрузки Linux.
• proc_pid_stat(5) — состояния процессов в /proc.
• journalctl(1) — фильтрация системного журнала по службе, времени и приоритету.
• ss(8) — просмотр сокетов и слушающих портов.
• df(1) — использование пространства и inode файловых систем.