Как мониторить Linux-сервер без платных инструментов

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

CPU и память: top и htop

top предустановлен везде; htop читается легче, и его стоит установить:

apt install htop      # Debian/Ubuntu
dnf install htop      # RHEL/Alma/Rocky
htop

Сначала смотрите на load average: три числа, показывающие средние значения за 1, 5 и 15 минут. Правило простое: сравнивайте нагрузку с количеством ядер, которое выводит nproc. Load 4.0 на сервере с 4 ядрами означает, что CPU полностью занят. Если нагрузка устойчиво держится выше числа ядер, процессы стоят в очереди и всё замедляется. Load 2.5 на 8 ядрах это ничего; load 2.5 на 1 ядре это проблема.

Важны ещё два поля. wa (iowait) в строке CPU показывает долю времени, которое процессор проводит в ожидании диска: если она стабильно выше 10 процентов, узкое место у вас не CPU, а хранилище, и стоит перейти к iostat. По памяти смотрите на колонку RES у каждого процесса (реально используемая RAM, в отличие от почти бессмысленной VIRT) и оценивайте по доступной памяти, а не по свободной: Linux намеренно использует свободную RAM под дисковый кеш и отдаёт её по требованию.

Дисковый ввод-вывод: iostat и что означает await

iostat входит в пакет sysstat:

apt install sysstat
iostat -x 5

Команда выводит расширенную статистику каждые 5 секунд. Первый блок игнорируйте, это среднее с момента загрузки. Важны две колонки:

• r_await / w_await: среднее время в миллисекундах, которое занимает запрос на чтение или запись, включая ожидание в очереди. Это лучший отдельный показатель на вопрос "тяжело ли моему диску".
• %util: насколько занято устройство. 100 процентов на современном SSD не приговор, так как он обслуживает запросы параллельно, но в сочетании с высоким await это подтверждает насыщение.

Ориентиры для await: NVMe должен держаться ниже 1 мс, SATA SSD от 1 до 5 мс, вращающиеся диски от 5 до 15 мс. Устойчивые десятки миллисекунд означают, что хранилище стало узким местом: либо какой-то процесс истязает диск (найдите его через iotop или pidstat -d 5), либо том действительно слишком медленный для этой нагрузки.

Место на диске: df, du и правило 80 процентов

df -h показывает заполнение по каждой файловой системе. Рабочее правило: действуйте при 80 процентах. Дальше у баз данных и сервисов с активными логами запас заканчивается быстро, а полностью заполненный корневой раздел ломает всё некрасивым образом: сервисы не могут записать PID-файлы, обновления останавливаются на полпути, иногда невозможно даже нормально войти.

df -h
df -i

df -i проверяет inode: раздел может быть заполнен при свободных гигабайтах, если миллионы мелких файлов (сессии, кеш, почтовая очередь) съели все inode. Чтобы найти, что реально занимает место, спускайтесь с помощью du:

du -xh --max-depth=1 / | sort -h | tail -15
du -sh /var/log/* | sort -h | tail -10

Обычные подозреваемые: /var/log, старые бэкапы и журнал systemd. Ограничьте журнал, чтобы он перестал расти:

journalctl --vacuum-size=500M

Логи и соединения: journalctl и ss

Когда что-то ведёт себя странно, сначала спросите журнал, а не гадайте:

journalctl -p err -b
journalctl -u nginx --since "1 hour ago"
journalctl -f
journalctl -k --grep=oom

Первая команда выводит все ошибки с момента загрузки, вторая ограничивается одним сервисом, третья следит в реальном времени. Последняя ищет в сообщениях ядра OOM killer: если процесс исчез без следа, ядро скорее всего убило его за то, что он съел всю RAM, и записано это именно здесь.

Для сетевых вопросов ss заменил netstat:

ss -tulpn
ss -s
ss -tn state established | wc -l

ss -tulpn показывает каждый слушающий сокет и процесс за ним. Запускайте после каждого деплоя; всё, что вы не узнаёте, заслуживает разбирательства. ss -s выводит итоги, а подсчёт установленных соединений во времени подскажет, всплеск это реального трафика или соединения, зависшие из-за сломанного клиента или медленного бэкенда.

Cron-проверка с оповещениями в Telegram или на почту

Базовое оповещение о доступности можно собрать самому за пять минут. Создайте бота через @BotFather в Telegram, скопируйте токен, отправьте боту одно сообщение и получите свой числовой chat id:

curl -s "https://api.telegram.org/bot$TOKEN/getUpdates"

Сохраните это как /usr/local/bin/healthcheck.sh и сделайте исполняемым:

#!/bin/bash
URL="https://example.com/health"
TOKEN="123456:AA...токен-вашего-бота"
CHAT="987654321"

CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$URL")
if [ "$CODE" != "200" ]; then
    curl -s "https://api.telegram.org/bot$TOKEN/sendMessage" \
        -d chat_id="$CHAT" -d text="ALERT: $URL вернул HTTP $CODE"
fi

Затем поставьте запуск каждые 5 минут:

*/5 * * * * /usr/local/bin/healthcheck.sh

Предпочитаете почту? Замените вызов Telegram на echo "$URL вернул $CODE" | mail -s "Server alert" you@example.com, для чего нужны mailutils и настроенный MTA. Тот же скрипт может следить и за правилом 80 процентов для диска: читайте заполнение через df -P / | awk 'NR==2 {print $5}' и оповещайте при пересечении порога.

Одна честная оговорка: запускайте проверку с другой машины, а не с той, которую мониторите. Упавший сервер не может сообщить о себе сам. Хватит самого дешёвого второго VPS или Raspberry Pi дома.

Когда переходить на настоящий мониторинг

Ручной набор инструментов перестаёт хватать в предсказуемый момент. Переходите на полноценную систему, когда что-то из этого становится правдой:

• У вас больше двух или трёх серверов, и вы заходите на каждый, чтобы их проверить.
• Вам нужна история: htop не ответит на вопрос "тормозил ли диск вчера в 14:30".
• Вы хотите оповещения о тенденциях, например о диске, который через три дня дойдёт до 80 процентов, а не только "работает или нет".
• Состояние системы должен видеть кто-то кроме вас.

Стандартный бесплатный self-hosted ответ: Prometheus с node_exporter и Grafana, либо Zabbix, если вам ближе одна интегрированная система; Netdata даёт мгновенную посекундную картину одной машины. Всё это свободное ПО с реальной ценой в виде времени на установку и сопровождение, поэтому внедряйте его тогда, когда ручные проверки начинают съедать часы.

И будьте честны с тем, что говорят цифры. Если load постоянно держится выше числа ядер или await на загруженном диске продолжает расти, решение это больше железа, а не больше графиков: сравните свои показатели с нашими тарифами VPS, прежде чем тратить неделю на оптимизацию. А если вы вообще не хотите читать графики в три часа ночи, наша команда IT поддержки возьмёт на себя мониторинг и реагирование на инциденты.