Debian 12: мониторинг из коробки с нуля

MAATRIX

Чтобы вовремя заметить, что сервер задыхается от нагрузки или заполнил диск, не нужны тяжёлые платные панели. Мониторинг Debian 12 из коробки с нуля строится на штатных утилитах, которые уже есть в системе или ставятся одной командой. Научившись читать их вывод, вы будете видеть нагрузку процессора, расход памяти, свободное место, сетевые соединения и логи служб. Разберём главные инструменты и что именно смотреть в каждом.

Зачем нужен базовый мониторинг

Сервер редко ломается внезапно — обычно он подаёт сигналы заранее: растёт нагрузка, заканчивается память, забивается диск, служба начинает перезапускаться. Если регулярно снимать эти показатели, проблему видно на подходе, и её можно решить до аварии. Мониторинг «из коробки» тем и хорош, что не добавляет на сервер лишних служб, которые сами потребляют ресурсы и создают новую поверхность атаки. Для минималистичного Debian это особенно органично.

Есть ещё причина полюбить штатные средства, а не сразу ставить панель. Тяжёлые системы наблюдения сами потребляют память и процессор, а на маленьком VPS каждый мегабайт на счету — получается парадокс, когда инструмент слежки за нагрузкой сам становится источником нагрузки. Штатные команды запускаются только в момент вызова и ничего не едят в фоне. К тому же они одинаковы почти на любом Linux-сервере: научившись читать их здесь, вы будете как дома на любой другой машине. Это универсальный навык, который окупается всю жизнь администратора.

Смотрим нагрузку через htop

Первый инструмент — htop, наглядный интерактивный диспетчер процессов. В минимальном Debian его обычно нет, но ставится он мгновенно:

apt install -y htop

Запустите его командой htop. Вверху вы увидите полоски загрузки по ядрам процессора, использование памяти и swap, а ниже — список процессов, отсортированный по нагрузке. Это первое место, куда стоит заглянуть при жалобе «сервер тормозит»: сразу видно, какой процесс съедает CPU или память. Обратите внимание на показатель load average в правом верхнем углу — три числа показывают среднюю нагрузку за 1, 5 и 15 минут. Если они устойчиво превышают число ядер вашего сервера, система перегружена. Выход из htop — клавиша F10 или q.

Проверяем память и диск

Память смотрят командой:

free -h

Обращайте внимание на колонку available — это реально доступная приложениям память с учётом кэша, а не пугающе малое «free». Linux намеренно занимает свободную память под кэш, и это нормально. Дисковое пространство проверяют так:

df -h

Команда покажет заполненность каждого раздела в процентах. Строка с корнем / — самая важная: если она подходит к 100%, сервер вот-вот начнёт сбоить, потому что многим службам негде писать. Найти, что именно занимает место, помогает du -sh /var/* | sort -h — она покажет размеры папок по возрастанию. Чаще всего виновники — разросшиеся логи и старые бэкапы.

Отдельно стоит понимать разницу между «диск кончился по месту» и «диск кончился по inode», потому что вторая проблема ставит новичков в тупик. Обычно место заканчивают крупные файлы, и это видно в df -h. Но файловая система хранит ещё и таблицу inode — записей о самих файлах, и если на диске лежат миллионы крошечных файлов (типичная беда почтовых очередей, сессий или кэшей), inode могут закончиться раньше места. Тогда система отказывается создавать новые файлы, хотя df -h показывает свободные гигабайты, — картина сбивает с толку. Проверить остаток inode помогает команда df -i. Если она показывает 100% использования при свободном месте, значит, дело именно в мелких файлах, и искать надо каталог, где их накопились сотни тысяч. Знание про эти два разных предела экономит часы недоумённого разбирательства.

Читаем логи через journalctl

В Debian логи собирает systemd, и главный инструмент их чтения — journalctl. Чтобы посмотреть последние записи в реальном времени:

sudo journalctl -f

Флаг -f (follow) выводит новые строки по мере появления — удобно ловить ошибку в момент возникновения. Чтобы посмотреть логи конкретной службы, укажите её через -u, например sudo journalctl -u nginx -n 50, где -n 50 показывает последние 50 строк. Это первое, куда стоит смотреть, если служба не запускается или ведёт себя странно: в логе почти всегда есть внятное сообщение об ошибке. Журнал systemd умеет фильтровать по времени (--since "1 hour ago") и по уровню важности (-p err покажет только ошибки), что резко ускоряет поиск причины сбоя.

Контролируем службы и сеть

Состояние любой службы показывает systemctl:

systemctl status nginx

Вывод скажет, запущена ли служба (active/running), когда стартовала и последние строки её лога. Команда systemctl list-units --failed покажет все службы, которые упали, — отличная утренняя проверка «всё ли в порядке». Сетевые соединения и открытые порты смотрят через ss:

sudo ss -tulpn

Флаги означают: TCP и UDP порты, только слушающие, с номерами и именами процессов. Так вы видите, какие программы принимают соединения снаружи, — и если замечаете лишний открытый порт, это повод разобраться, что за служба его слушает и нужна ли она вообще. Регулярная сверка открытых портов — простая, но действенная привычка безопасности.

Собираем привычку и автоматизируем

Отдельные команды хороши для разовой диагностики, но настоящий мониторинг — это привычка смотреть на сервер регулярно. Заведите короткий утренний ритуал: df -h (не кончается ли диск), free -h (хватает ли памяти), systemctl --failed (не упало ли что-то), journalctl -p err --since yesterday (не сыпались ли ошибки за ночь). Пять минут в день экономят часы разбора аварий. Отдельно освойте чтение показателя нагрузки: три числа load average сами по себе ничего не значат, пока вы не соотнесёте их с числом ядер сервера — значение 1.0 на одноядерном означает полную загрузку, а на четырёхъядерном лишь четверть мощностей. Если серверов станет много или захочется графиков и оповещений, поставьте лёгкий netdata — он даёт наглядные дашборды почти без нагрузки. Но начинать всегда стоит со штатных утилит: они работают везде и учат понимать, что происходит внутри системы, а не просто смотреть на цветные графики.

Частые вопросы