Какими командами можно диагностировать базовые проблемы в Linux

Диагностика базовых проблем в Linux

Как DevOps Engineer с большим стажем, я рассматриваю диагностику в Linux как системный процесс, от общего к частному. Вот ключевые команды и подходы, сгруппированные по категориям проблем.

1. Мониторинг системы и ресурсов

Первое, что я делаю при любой непонятной проблеме — смотрю на общее состояние системы.

Команды для проверки нагрузки и ресурсов:

# Балансовая сводка системы (самая важная команда!)
htop

# Или классический top
top

# Проверка использования памяти
free -h

# Подробная информация о памяти (буферы, кеш, slab)
cat /proc/meminfo

# Мониторинг дискового ввода-вывода
iostat -x 2

# Или более удобный iotop
iotop

# Нагрузка на сетевые интерфейсы
nload eth0

2. Диагностика проблем с дисками и файловой системой

Ключевые команды для работы с дисками:

# Проверка свободного места на дисках
df -h

# Но я предпочитаю более читаемый вывод с типами файловых систем
df -hT

# Поиск больших файлов (когда диск неожиданно заполнился)
find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null

# Проверка inode (частая скрытая проблема!)
df -i

# Мониторинг использования диска в реальном времени
du -sh /var/* 2>/dev/null | sort -hr | head -10

# Проверка целостности файловой системы (если система не загружается)
fsck /dev/sda1

3. Сетевые проблемы

Для DevOps сетевая диагностика — ежедневная рутина.

Базовый сетевой стек:

# Проверка сетевых интерфейсов и IP-адресов
ip addr show

# Или классика
ifconfig -a

# Проверка маршрутизации
ip route show
# или
route -n

# Тестирование базовой связности
ping -c 4 google.com

# Проверка DNS разрешения
nslookup google.com
# или
dig google.com A +short

# Анализ сетевых соединений
ss -tulpn

# Более подробная информация о процессах, использующих сеть
netstat -tulpn

# Трассировка маршрута
traceroute google.com
# или современная версия
tracepath google.com

4. Процессы и службы

Когда что-то работает не так, нужно найти "виновника".

Диагностика процессов:

# Поиск процесса по имени
pgrep -a nginx

# Или более информативно
ps aux | grep nginx

# Проверка потребления ресурсов конкретным процессом
pidstat -p <PID> 2 5

# Дерево процессов (чтобы понять родительские связи)
pstree -p

# Проверка открытых файлов процессом (очень полезно!)
lsof -p <PID>

# Поиск, какой процесс использует порт
lsof -i :80

5. Анализ логов

Основные подходы к работе с логами:

# Просмотр логов в реальном времени
tail -f /var/log/syslog

# Для systemd систем
journalctl -f

# Поиск ошибок в логах
grep -i error /var/log/syslog | tail -20

# Анализ логов за определенный период
journalctl --since "1 hour ago" --until "now"

# Просмотр специфичных логов сервисов
tail -100 /var/log/nginx/error.log

6. Производительность системы

Профилирование проблем с производительностью:

# Комплексный анализ производительности (моя любимая!)
vmstat 2 10

# Статистика процессов
mpstat -P ALL 2 5

# Нагрузка на CPU по ядрам
sar -u 2 5

# Детальный ввод/вывод
iostat -dx 2 5

# Мониторинг контекстных переключений
pidstat -w 2 5

7. Проблемы с загрузкой и ядром

Когда система не загружается или есть проблемы с ядром:

# Проверка сообщений ядра
dmesg | tail -50

# Или с временными метками
dmesg -T | tail -50

# Просмотр логов загрузки
journalctl -b

# Проверка текущей версии ядра
uname -a

# Анализ использования модулей ядра
lsmod

Мой рабочий процесс диагностики

Когда я сталкиваюсь с проблемой, я следую определенному алгоритму:

1. Быстрая оценка — htop, df -h, ss -tulpn
2. Идентификация симптомов — что именно не работает? Медленно? Недоступно? Ошибки?
3. Анализ логов — journalctl -f, tail -f соответствующих логов приложения
4. Глубокое профилирование — если проблема персистирует, запускаю vmstat, iostat, pidstat
5. Поиск узких мест — анализирую метрики, ищу корреляции

Важный совет: всегда смотрите на временные метки! Часто проблема начинается гораздо раньше, чем ее заметили. Используйте date для проверки времени на сервере и коррелируйте с логами.

Для DevOps особенно важно не просто диагностировать проблему, но и автоматизировать диагностику. Я часто создаю скрипты, которые собирают всю эту информацию одним вызовом, что критично при инцидентах в 3 часа ночи. Современный подход — интеграция этих команд в системы мониторинга типа Prometheus + Grafana, чтобы проблемы были видны до того, как они станут критическими.