Блог компании 3v-Hosting
10 мин.
Хорошо настроенный изначально Linux-сервер может месяцами работать без заметных проблем, а все сервисы на нём могут работать вполне стандартно. Сайты открываются, база данных отвечает, SSH доступен и никаких проблем вроде бы не наблюдается. Тем временем размер логов на сервере постоянно растёт, копятся обновления, заканчиваются inode, остаются старые и неактуальные SSH-ключи и так далее и тому подобное. То есть со временем ваш сервер в любом случае будет захламляться.
Поэтому приблизительно раз в месяц будет полезно пройтись по серверу и оценить его работу, от общего состояния системы до приложений и резервных копий. По хорошему такая проверка не должна превращаться в многочасовой аудит, то есть все шаги должны быть простыми и понятными, а вот результат должен быть понятным и предсказуемым.
Нам показалось, что это будет полезным для наших читателей и мы решили кратко описать последовательность действий и команд, которые можно использовать для ежемесячного аудита вашего VPS, выделенного сервера или даже небольшой production-инфраструктуры. Поехали.
Как и в любом деле, начинать лучше с понимания общей картины, прежде чем бросаться что-то обновлять и перезапускать сервисы. Для этого используется набор стандартных команд:
uptime free -h df -h df -i systemctl --failed timedatectl
Здесь нас в первую очередь интересуют нагрузка, память и swap, свободное место, inode, упавшие systemd units и корректность системного времени.
С цифрами, правда есть нюанс. Например, занятая оперативная память сама по себе мало о чем говорит, так как Linux активно использует память под кэш. Куда полезнее будет сравнивать текущее состояние с обычным состоянием именно этого сервера.
То же самое и с диском. К примеру каталог/var, который стабильно занимает 70 ГБ, может быть вполне нормой. А вот рост его объёма с 35 до 70 ГБ за пару месяцев - это уже повод искать причину.
Когда мы смотрим на текущее состояние сервера - это ничего не говорит нам о состоянии системы даже в недавнем прошлом. А ведь сервер мог испытывать какие либо проблемы пару недель назад, а сейчас выглядеть совершенно здоровым. Поэтому обязательным этапом в таком аудите является проверка основных журналов сервера на нестандартные события в прошлом:
journalctl -p warning..alert --since "30 days ago" journalctl -k -p warning..alert --since "30 days ago"
И отдельно поищем события OOM (Out Of Memory):
journalctl -k --since "30 days ago" | grep -Ei 'oom|out of memory|killed process'
Повторяющиеся ошибки намного важнее и интереснее единичной записи, особенно если это проблемы диска, файловой системы, сети или регулярно падающего сервиса.
OOM тоже легко пропустить, ведь сегодня на сервере может быть несколько гигабайт свободной оперативной памяти, хотя неделю назад ядро, например, завершило PostgreSQL или PHP-FPM из-за нехватки памяти.
Обновления Linux-дистрибутивов выходят постоянно. В них исправляются найденные ошибки, закрываются обнаруженные уязвимости, обновляются системные библиотеки и отдельные компоненты системы. На давно работающем сервере часть таких пакетов может месяцами оставаться в старой версии, особенно если автоматическая установка обновлений не была настроена.
Поэтому во время ежемесячного обслуживания стоит проверить то, какие обновления доступны. Сразу устанавливать все подряд необязательно и для начала нужно посмотреть список предлагаемых пакетов, чтобы понять, что именно изменится.
Для Debian и Ubuntu это можно сделать командами:
apt update apt list --upgradable
Для RHEL-подобных систем:
dnf check-update
В первую очередь в полученном списке необходимо обратить внимание на ядро, OpenSSH, системные библиотеки, СУБД, веб-сервер и ПО, которое принимает подключения из интернета, так как уязвимости чаще всего обнаруживаются именно там.
Безусловно, критические обновления безопасности нужно устанавливать сразу после их выхода, не откладывая до планового обслуживания. А во время такой ежемесячной проверки достаточно лишь посмотреть, какие обновления накопились с прошлого раза и какие из них нужно установить.
После установки пакетов в Debian и Ubuntu проверим, нужна ли перезагрузка:
test -f /var/run/reboot-required && cat /var/run/reboot-required
Текущее ядро можно посмотреть отдельно командой:
uname -r
Это полезно делать после обновления kernel-пакетов, так как новое ядро уже может находиться на диске, но до перезагрузки сервер продолжит работать на старой версии, что не совсем то, чего мы добиваемся.
Дисковое пространство на сервере расходуется постоянно, так как постоянно и непрерывно растут системные журналы, приложения создают временные файлы, после обновлений остаются старые пакеты и ядра и т.п. и т.п. И если свободное место на диске вашего сервера заканчивается, то проблемы могут появиться сразу у нескольких классов сервисов, от базы данных до веб-сервера. Поэтому во время ежемесячной проверки полезно посмотреть, какие каталоги растут быстрее обычного и сколько места занимают логи. Ну и, при необходимости, их почистить.
Теперь разберемся, куда конкретно уходит место.
du -xhd1 /var | sort -h journalctl --disk-usage
Если вырос /var/log, то смотрим уже внутри этого каталога подробнее:
du -xhd1 /var/log | sort -h
Если вы нашли какой либо большой лог, то не спешите его удалять. Сначала найдите источник, который пишет в этот лог и выясните, почему приложение пишет столько данных и работает ли ротация.
Заодно проверьте каталог /boot, старые архивы, временные файлы и настройки утилиты logrotate, которую мы крайне рекомендуем использовать. А как её установить и настроить - читайте в этой статье.
Также, при анализе логов, стоит помнить о такой особенности, что команда du может не отображать файлы, которые вроде бы были удалены, но какой либо процесс продолжает держать их открытым. А в результате место на диске остается занятым. Просмотреть такие файлы лучше командой:
lsof +L1
Если там обнаружился огромный удаленный файл, то попробуйте найти удерживающий его процесс и перезапустить его стандартными средствами.
Многие регулярные операции на сервере выполняются автоматически и обычно не требуют внимания администратора. Такие задачи как резервное копирование, продление сертификатов, очистка временных файлов и различные maintenance-скрипты могут месяцами работать по расписанию, не привлекая особого внимания. Проблемы могут возникнуть в том случае, если одна из таких задач по какой либо причине перестает выполняться, а заметных последствий поначалу нет.
Для проверки запланированных задач, systemd timers, используйте команду:
systemctl list-timers --all
Посмотрите время последнего запуска важных задач и дату следующего запуска, если какая-то задача давно не выполнялась или имеет странное расписание, то обязательно стоит проверить соответствующий сервис и его журнал.
Для cron проверьте сами задания и их фактическое выполнение по логам. Особое внимание имеет смысл уделить резервному копированию, автоматическим скриптам обслуживания и другим задачам, от которых зависит работа сервера.
Только помните, что сам факт наличия определенной строки в crontab еще не означает, что скрипт успешно запускается, ведь он может завершаться с ошибкой, не иметь нужных прав или обращаться к недоступному файлу, что приводит его к падению. Поэтому здесь нас интересует именно результат последнего выполнения задания. Кстати, про настройку cron у нас есть отдельная краткая статья.
Даже если сервер работает стабильно, то раз в месяц всё равно будет полезно проверить, кто имеет к нему доступ и какие сервисы доступны из сети. Со временем могут оставаться старые учетные записи, забытые SSH-ключи или открытые порты, которые больше не нужны. Конечно, проводить полный аудит безопасности системы каждый месяц - избыточно. А вот для ежемесячной простой проверки достаточно пары-тройки простых стандартных команд:
last ss -lntup getent group sudo
Эти команды отобразят информацию о:
Список открытых портов обязательно нужно сверить с сервисами, которые действительно должны быть доступны на этом сервере. Если вдруг обнаружился незнакомый порт или пользователь, то сначала выясните, откуда он появился и нужен ли он сейчас.
Особенно полезно пройтись по доступам после работы подрядчиков или временных сотрудников, так как старый SSH-ключ легко переживает человека, которому его когда-то выдали.
Ну и конечно, если в ходе такой базовой проверки вы выявили какие-то подозрительные "улики" - тогда обязательно нужно провести полноценный аудит безопасности сервера, чтобы нивелировать возможность компрометации системы.
Сама Linux-система - это лишь операционная система и она вполне может работать нормально, в то время как проблема развивается на уровне того или иного приложения.
Для веб-серверов Nginx или Apache обязательно нужно просмотреть журнал ошибок и просмотреть файлы конфигурации. Для баз данных PostgreSQL или MariaDB - проверить состояние сервиса, ошибки, размер данных и свободное место на диске. Конкретный набор проверок, очевидно, зависит конечных задач сервера и в связи с этим от набора установленного ПО.
Так, например, если вы используете Docker, то стоит посмотреть на перечень остановленных контейнеров и на расход дискового пространства:
docker ps -a docker system df
А вот автоматически запускать docker system prune -a по расписанию - это плохая и губительная привычка, ведь сначала нужно разобраться, какие данные действительно больше не нужны и лишь потом удалять их. Ну а в работе с в volumes нужна особая осторожность.
Отдельным классом стоят всевозможные сертификаты. Даже при автоматическом продлении сертификатов полезно иногда посмотреть, что сервер реально отдает клиенту. Для этого используйте подобную команду:
echo | openssl s_client -connect example.com:443 \ -servername example.com 2>/dev/null | \ openssl x509 -noout -dates
Так проверяется именно активный на данный момент сертификат, ведь файл на диске мог обновиться, а вот веб-сервер по какой-то причине может продолжить использовать старый сертификат.
А вот контроль срока действия сертификатов лучше будет вынести в мониторинг и настроить уведомления, чтобы узнавать о проблеме заранее и успеть обновить сертификаты до того, как сайт перестанет открываться.
Резервное копирование имеет смысл только тогда, когда данные из копии действительно можно восстановить. Эта мысль кажется очевидной, но очень часто администраторы просто складывают резервные копии "в кучку", а когда возникает необходимость срочно восстановить данные из бекапа - этого просто не получается сделать по той или иной причине, будь то неподходящие форматы файлов или проблемы в самом процессе. Поэтому условный зеленый статус последнего бэкапа - это только половина проверки.
Лучшим решением будет, если вы раз в месяц возьмёте реальную резервную копию и попробуете восстановить ее в изолированной среде, например на временной виртуальной машине, тестовом VPS или на отдельном диске.
После восстановления проверьте данные и базу, права и владельцев файлов, запуск сервисов. Посмотрите и на дату восстановленных данных, так как пригодная копия может неожиданно оказаться гораздо старше ожидаемого.
Также проверьте несколько последних заданий резервного копирования. Если одна из задач завершалась с ошибкой или стала выполняться заметно дольше обычного, то стоит сразу выяснить причину.
Загляните и в backup storage, так как свободное место там тоже имеет тенденцию заканчивается, а переполненное хранилище в какой-то момент просто перестанет принимать новые копии.
После такого базового ежемесячного обслуживания обязательно стоит зафиксировать актуальное состояние сервера. Подробный отчет для этого не нужен и достаточно просто записать несколько показателей и найденные проблемы, чтобы при следующей проверке было с чем сравнивать.
Саму ежемесячную проверку можно свести к такой последовательности:
/var, /var/log, /boot и journal;
Для фиксирования и отслеживания истории проверок достаточно небольшой таблицы в произвольном формате, типа:
| Показатель | Август | Сентябрь |
|---|---|---|
/var |
48 ГБ | 61 ГБ |
| Backup storage | 54% | 67% |
| Failed units | 0 | 0 |
| OOM events | 0 | 2 |
Такая запись помогает увидеть изменения во времени, которые сложно заметить при разовой проверке. Например, занятые 61 ГБ в /var сами по себе мало о чем говорят. А вот рост этого показателя с 48 до 61 ГБ за месяц уже требует пристального внимания. То же самое касается и появления OOM-событий или быстрого заполнения хранилища резервных копий.
Ну и стоит иметь в виду, что некоторые наиболее критические и важные показатели лучше вынести в постоянный мониторинг с алертами.
Правда периодическая ручная проверка при этом всё равно остается полезной. Мониторинг, например, сообщит, что каталог /var быстро растет, а администратор сможет отыскать причину такого стремительного роста. Или вот система резервного копирования покажет успешное выполнение задания, а тестовое восстановление подтвердит, что сохраненными данными действительно можно воспользоваться в чрезвычайной ситуации.
Ну и подводя итог, стоит отметить, что ежемесячное обслуживание Linux-сервера не требует много времени и сил, если проводить его по понятному чек-листу. А результаты будут наглядными, если вести историю проверок хотя-бы в свободном формате. Регулярная проверка состояния системы, обновлений, дисков, фоновых задач, безопасности и резервных копий помогает заметить небольшие проблемы до того, как они начнут мешать работе вашего сервера.
Для небольшого VPS или отдельного сервера полноценной ручной проверки раз в месяц обычно достаточно. При этом состояние дисков, доступность сервисов, ошибки резервного копирования и другие критичные события лучше отслеживать постоянно с помощью мониторинга.
Нет. Перезагружать сервер просто по расписанию нет смысла. Обычно это делают после обновления ядра или других системных компонентов, которым для применения изменений требуется reboot. Долгий uptime сам по себе проблемой не является.
Обычно нет. За ротацию и удаление старых журналов отвечают logrotate, systemd-journald или само приложение. Если какой-то лог внезапно вырос до нескольких гигабайт, сначала выясните причину. Простое удаление файла освободит место, но проблема вскоре появится снова.
Самый надежный вариант - восстановить ее в изолированной среде и проверить данные, базу, права доступа и запуск приложения. Успешное создание backup еще не гарантирует, что из него получится восстановить рабочий сервер.
Сначала выясните, какой раздел и какие каталоги растут. Часто причиной оказываются логи, временные файлы, старые архивы, Docker-данные или накопившиеся резервные копии. Удалять самые большие файлы вслепую не стоит - сначала нужно понять, зачем они нужны и какой процесс их создает.
Чаще всего находятся вещи, которые пока не мешают работе сервера: накопившиеся обновления, растущие логи, ошибки фоновых задач, старые SSH-ключи или нехватка места в backup storage. Такая проверка как раз и нужна, чтобы разобраться с ними до появления заметных последствий.
В первую очередь - контроль свободного места, нагрузки и памяти, доступности сервисов, ошибок резервного копирования, OOM и срока действия TLS-сертификатов. Если проблема требует реакции сразу после появления, ждать следующей ручной проверки нет смысла.
Часто в интернете мы слышим о злых и коварных хакерах, которые взломали чей нибудь аккаунт или почту. И таких сообщений с годами становится только больше. Очеви...
Поскольку популярность виртуальных частных серверов (VPS) продолжает расти, растет и важность эффективного мониторинга этих систем. Linux VPS, в частности, пред...
Одним из базовых инструментов в арсенале любого сетевого инженера или системного администратора является инструмент для опроса DNS серверов - nslookup, который ...
Оптимизация загрузки Linux-сервера помогает найти задержки в systemd, сети, ядре и fstab, проверить критическую цепочку и сократить общее время запуска системы.
Что делать, если закончилось место в /var на Linux-сервере. Пошаговая диагностика и безопасная очистка логов, Docker, journald и APT в Debian и Ubuntu.
Настройка gzip и Brotli в Nginx: сжатие HTML, CSS и JavaScript, выбор уровня компрессии, снижение нагрузки на сервер, проверка и решение типичных проблем.
