AlmaLinux 9: мониторинг из коробки с нуля

MAATRIX

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

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

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

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

Ставим htop через EPEL

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

dnf install -y epel-release
dnf install -y htop

EPEL (Extra Packages for Enterprise Linux) — это официальный набор полезных пакетов, которых нет в базовом репозитории RHEL. Он пригодится не только для htop, но и для fail2ban, certbot и множества других инструментов, так что подключить его на сервере полезно сразу. Запустите htop одноимённой командой: вверху вы увидите полоски загрузки по ядрам, использование памяти и swap, ниже — список процессов по нагрузке. Это первое место, куда стоит заглянуть при жалобе «сервер тормозит». Выход — клавиша F10 или q. Если ставить EPEL не хочется, всегда доступна встроенная команда top, менее наглядная, но работающая без дополнительных репозиториев.

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

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

free -h

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

df -h

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

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

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

sudo journalctl -f

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

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

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

systemctl status nginx

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

sudo ss -tulpn

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

Отдельно стоит различать, слушает ли служба порт на всех интерфейсах или только на локальном. В выводе ss -tulpn адрес вида 0.0.0.0:порт или *:порт означает, что служба принимает соединения откуда угодно, а 127.0.0.1:порт — что только с самой машины. Это важнейшее для безопасности различие: база данных, слушающая только локальный адрес, недоступна из интернета в принципе, даже если в фаерволе случайно открыть её порт. Поэтому хорошая практика — держать служебные программы вроде баз и кэшей привязанными к локальному адресу, а наружу выпускать только веб-сервер. Привыкнув читать колонку адреса в ss, вы с одного взгляда оцениваете, что именно и для кого доступно на сервере, и ловите потенциально опасные привязки ещё до того, как ими воспользуется кто-то чужой.

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

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

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