Представьте: вы получаете алерт "сервер тормозит" или замечаете странные лаги в приложении. Отставить панику)) В этой статье мы разберем, как провести технический осмотр Linux-сервера и найти корень проблемы без углубления в тонны логов.

Сейчас расскажем вам про методику RED S.O.S. - структурированный подход, который превращает хаотичную проверку в системный диагноз. Это ваш чеклист для экстренного реагирования. Он не заменяет системы мониторинга (Prometheus, Zabbix), но дает моментальный снимок здоровья системы.

Фокус здесь на ключевых ресурсах: Resources (Ресурсы), Errors (Ошибки), Dependencies (Зависимости)

[R] Resources - Ресурсы

Цель: Определить, какое из железных ресурсов исчерпано.

1. Load Average & CPU: Что на самом деле означает «нагрузка»?

htop
# Или, если htop нет:
cat /proc/loadavg

• Load Average (LA) - это не процент. Это средняя длина очереди процессов, готовых к выполнению (состояние R) или ожидающих I/O (состояние D).

• Интерпретация: Сравните LA с количеством ядер CPU (nproc). LA = 8 на 4-ядерной машине означает, что в среднем 2 процесса стояли в очереди на каждое ядро. Высокий LA при низком %us (user CPU) - классический симптом I/O-голодания.

2. Память: Кеш

free -h

• Забудьте про колонку free. Смотрите на available. Это память, которую можно отдать приложениям прямо сейчас, включая кеш, который ядро немедленно освободит.

• Тревожный сигнал: Активное использование Swap. Если si/so (swap in/out) в vmstat 1больше 0, физическая память исчерпана, и система деградирует.

3. Диски: Место и производительность

# Свободное место
df -hT | grep -v tmpfs

# Производительность (пакет sysstat)
iostat -dx 1 3

• %util > 80%: Устройство насыщено.

• await > 20 мс (для HDD): Запросы слишком долго ждут в очереди. Виновник - или медленный диск, или чрезмерная нагрузка.

[E] Errors - Ошибки и аномалии

Цель: Найти следы сбоев на уровне ОС и сети.

1. Проверьте системные журналы на предмет критических ошибок за последние 5 минут

journalctl --since "5 minutes ago" -p err..emerg

• Ищите сообщения от OOM-killer, аппаратные сбои (smartd), проблемы с файловой системой.

2. Сетевые ошибки и выбросы

# Показать статистику по сетевым интерфейсам
ip -s link

• Обратите внимание на колонки errors, dropped. Растущие счетчики указывают на проблемы с сетью или нехваткой ресурсов на стороне ОС.

[D] Dependencies - Зависимости

Цель: Убедиться, что сервер может общаться с миром и его сервисы доступны.

1. Сетевые соединения

# Современная замена netstat
ss -tlnp

• Убедитесь, что ваши ключевые сервисы (веб-сервер, база данных) находятся в состоянии LISTEN на ожидаемых портах.

2. Базовая связность

# Проверяем не только доступность, но и DNS
ping -c 2 ya.ru
ping -c 2 <ip-вашего-внутреннего-сервера>

• Если первый ping не работает, а второй работает, проблема в DNS или маршрутизации вовне.

Суммируем

Действуйте по порядку, ответив на 5 ключевых вопросов:

1. LA высокий? Если да, значит смотрим %wa в iostat и %CPU в htop.

2. Память исчерпана? Смотрите available в free -h и активность swap.

3. Диск переполнен? df -h.

4. Дисковая подсистема насыщена? iostat -dx 1 3 (смотрим %util, await).

5. Сервисы слушают и порты открыты? ss -tlnp.

Ответы на эти вопросы с вероятностью 95% локализуют проблему.

Ручные проверки = «скорая помощь». Для постоянного здоровья используйте:

• Prometheus + Grafana: Классика для сбора и визуализации метрик. Легко мониторить все, что мы проверили вручную.

• Netdata: Быстрая установка и полнофункциональные дашборды в базовой комплектации.

• eBPF-инструменты (bcc-tools): Позволяют заглянуть глубже, например, посмотреть на задержки ввода-вывода на уровне отдельных процессов с помощью biolatency.

Методика RED S.O.S. - ваш план быстрого реагирования при первых признаках нестабильности. Сохраните его, дополните своими наработками и используйте на здоровье :)