Ubuntu 24.04: мониторинг из коробки с нуля

MAATRIX

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

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

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

Штатные утилиты дают полную картину здоровья системы четырьмя срезами: процессор и память, дисковое пространство, сеть, состояние служб и логи. Освоив по одному инструменту на каждый срез, вы закрываете 90% задач диагностики без единой сторонней программы. Именно с этого стоит начинать — а красивые дашборды подключать позже, когда серверов станет много. Пройдёмся по инструментам по порядку.

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

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

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

sudo 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 — она покажет размеры папок по возрастанию. Чаще всего виновники — разросшиеся логи и старые бэкапы.

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

В Ubuntu логи собирает 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 порты, только слушающие, с номерами и именами процессов. Так вы видите, какие программы принимают соединения снаружи, — и если замечаете лишний открытый порт, это повод разобраться, что за служба его слушает и нужна ли она вообще. Регулярная сверка открытых портов — простая, но действенная привычка безопасности.

Отдельно стоит освоить чтение показателя uptime и нагрузки, потому что он часто вводит в заблуждение. Команда uptime показывает, сколько сервер работает без перезагрузки, и те же три числа load average, что и htop. Ключ к их пониманию — соотносить с числом ядер: значение 1.0 на одноядерном сервере означает полную, но не избыточную загрузку, а на четырёхъядерном — что заняты лишь четверть мощностей. Поэтому «нагрузка 2.0» сама по себе ничего не говорит, пока вы не знаете, сколько у сервера ядер. Смотреть стоит и на динамику: три числа за 1, 5 и 15 минут показывают тенденцию. Если последнее (за 15 минут) заметно ниже первого (за минуту), нагрузка нарастает прямо сейчас, и это повод заглянуть в htop и найти виновника, пока сервер не встал.

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

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

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