Эксперт по Linux терминалу

Диск заполнен на 95%: диагностика и очистка /var/log и /var/lib/postgresql, настройка logrotate

1. Уточнение цели

Задача:

1. Найти, что занимает место в /var/log и /var/lib/postgresql.
2. Безопасно освободить место.
3. Настроить ротацию логов, чтобы диск не заполнялся снова.

Ограничения: файлы БД не трогаем, Nginx не останавливаем.

Предположения:

• /var лежит на корневом разделе /, файловая система ext4.
• PostgreSQL 14 установлен из пакетов Ubuntu. Кластер 14/main, данные в /var/lib/postgresql/14/main, логи в /var/log/postgresql/.
• Nginx установлен из пакетов Ubuntu, поэтому уже есть /etc/logrotate.d/nginx.
• logrotate на 22.04 запускается через logrotate.timer (systemd), а не через cron.

Два вопроса, которые могут изменить план. Пока исхожу из ответа «нет» на оба:

1. Есть ли репликация, архивирование WAL или агент бэкапов (pgBackRest, wal-g, Barman)? От этого зависит, что делать, если разросся каталог pg_wal.
2. Нужно ли хранить логи дольше N дней по требованиям (аудит, аналитика, 152-ФЗ и т. п.)? Ниже я закладываю 14 дней. Если нужно дольше, логи стоит выгружать на другой носитель, а не удалять.

⚠️ Главное правило: в /var/lib/postgresql/14/main (особенно в pg_wal/ и base/) ничего не удаляем руками. Удаление WAL-файлов вручную — самый частый способ безвозвратно потерять базу. Место там освобождается только средствами самого PostgreSQL.

2. Диагностика

Шаг 2.1. Общая картина по диску

df -h /
df -i /

• Назначение: показать занятость раздела по объёму и по inode.
• Флаги: -h выводит размеры в человекочитаемом виде. -i показывает inode вместо байтов: диск может «кончиться» из-за миллионов мелких файлов даже при свободных гигабайтах.
• Ожидаемо: строка вида /dev/vda1 40G 38G 2.0G 95% /. Если IUse% близок к 100%, проблема в количестве файлов, а не в объёме.

Шаг 2.2. Кто занимает место в /var

sudo du -xh --max-depth=1 /var 2>/dev/null | sort -h
sudo du -xh --max-depth=2 /var/log 2>/dev/null | sort -h | tail -15
sudo du -xh --max-depth=3 /var/lib/postgresql 2>/dev/null | sort -h | tail -15

• Назначение: найти самые тяжёлые каталоги.
• Флаги:
  • -x не выходит за пределы файловой системы (не посчитает смонтированные диски).
  • -h даёт человекочитаемые размеры, --max-depth=N задаёт глубину.
  • sort -h сортирует с учётом суффиксов K/M/G.
  • 2>/dev/null скрывает ошибки доступа.
• Зачем sudo: каталоги /var/log/* и /var/lib/postgresql закрыты для обычного пользователя, без прав du покажет заниженные цифры.
• Ожидаемо: внизу списка окажутся самые крупные каталоги, например /var/log/nginx, /var/log/journal или /var/lib/postgresql/14/main/pg_wal.

Шаг 2.3. Самые крупные файлы в логах

sudo find /var/log -xdev -type f -size +50M -printf '%s\t%TY-%Tm-%Td\t%p\n' | sort -n | numfmt --field=1 --to=iec

• Назначение: найти конкретные файлы крупнее 50 МБ с датой изменения.
• Разбор:
  • -size +50M отбирает файлы крупнее 50 МиБ.
  • -printf задаёт формат вывода: %s — размер в байтах, %T… — дата изменения, %p — путь.
  • numfmt --to=iec превращает байты в 1.2G.
• Ожидаемо: например, 3.4G 2026-09-23 /var/log/nginx/access.log. Если активный лог весит гигабайты, ротация для него не работает.

Шаг 2.4. Журнал systemd

journalctl --disk-usage

• Ожидаемо: Archived and active journals take up 2.1G in the file system. По умолчанию journald может занять до 10% раздела (но не более 4 ГБ).

Шаг 2.5. «Призрачные» файлы: удалены, но ещё открыты

sudo lsof -nP +L1 2>/dev/null | awk 'NR==1 || $7 > 10485760'

• Назначение: найти файлы, которые кто-то уже удалил через rm, но процесс (Nginx, Postgres) продолжает держать их открытыми. Место на диске освобождается только после закрытия файла.
• Флаги:
  • +L1 отбирает файлы с числом ссылок меньше 1, то есть удалённые.
  • -nP отключает резолв имён хостов и портов (так быстрее).
  • awk оставляет заголовок и файлы крупнее 10 МБ (7-я колонка — размер).
• Ожидаемо: пустой вывод. Если есть строки с (deleted), то df и du расходятся, и нужно переоткрыть логи у процесса (см. шаг 3.4).

Шаг 2.6. PostgreSQL: что именно растёт

Размеры баз:

sudo -u postgres psql -X -c "SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size FROM pg_database ORDER BY pg_database_size(datname) DESC;"

• sudo -u postgres: подключение идёт через peer-аутентификацию от системного пользователя postgres, пароль не нужен.
• -X: не читать ~/.psqlrc, чтобы вывод был предсказуемым.

Ключевые настройки:

sudo -u postgres psql -X -c "SHOW max_wal_size;" -c "SHOW wal_keep_size;" -c "SHOW archive_mode;" -c "SHOW logging_collector;" -c "SHOW log_directory;" -c "SHOW log_min_duration_statement;" -c "SHOW log_statement;"

• Смотрим:
  • logging_collector = on: логи пишутся внутрь data-каталога (14/main/log/), и системный logrotate их не видит.
  • log_statement = all или log_min_duration_statement = 0: в лог попадает каждый запрос, это верный путь к гигабайтам логов.

Если большой каталог pg_wal, проверьте слоты репликации и архиватор:

sudo -u postgres psql -X -c "SELECT slot_name, slot_type, active, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal FROM pg_replication_slots;"
sudo -u postgres psql -X -c "SELECT archived_count, failed_count, last_failed_wal, last_failed_time FROM pg_stat_archiver;"

• Ожидаемо: слотов нет или все active = t, а failed_count не растёт.
• Тревожные признаки:
  • Слот с active = f и retained_wal в гигабайтах. PostgreSQL держит WAL для реплики, которой больше нет.
  • Растущий failed_count при archive_mode = on. archive_command падает, и WAL копятся.

Самые крупные таблицы (подставьте имя базы):

sudo -u postgres psql -X -d ИМЯ_БД -c "SELECT relname, pg_size_pretty(pg_total_relation_size(relid)) AS total FROM pg_catalog.pg_statio_user_tables ORDER BY pg_total_relation_size(relid) DESC LIMIT 10;"

💡 Проверьте ещё домашний каталог пользователя postgres, то есть сам /var/lib/postgresql. Туда часто складывают дампы pg_dump по cron, и они копятся годами. Их можно удалять (после проверки), это не файлы БД.

3. Очистка

Шаг 3.0. Если диск заполнен на 100% (аварийный режим)

При полном диске падают sudo, редакторы и сам PostgreSQL. Сначала освободите немного места безопасными командами:

sudo apt-get clean
sudo journalctl --vacuum-size=200M

• apt-get clean удаляет кэш скачанных .deb из /var/cache/apt/archives. Это безопасно: пакеты при необходимости скачаются заново.
• --vacuum-size=200M удаляет архивные файлы журнала, пока общий объём не станет не больше 200 МБ. Активный журнал не трогается.
• Ожидаемо: Vacuuming done, freed 1.9G of archived journals from /var/log/journal/....

Шаг 3.1. Старые ротированные логи: сначала dry-run

sudo find /var/log -xdev -type f \( -name '*.gz' -o -name '*.[0-9]' -o -name '*.old' \) -mtime +14 -printf '%TY-%Tm-%Td  %8k KB  %p\n' | sort

• Назначение: показать, что будет удалено. Это только вывод, ничего не удаляется.
• Разбор:
  • \( … -o … \) — группа условий «ИЛИ». Скобки экранированы, чтобы bash не принял их за свой синтаксис.
  • *.gz — сжатые архивы, *.[0-9] — нумерованные копии вроде syslog.1, *.old — старые копии.
  • -mtime +14 отбирает файлы, изменённые больше 14 полных суток назад.
  • Активные *.log не попадают в выборку: у них нет таких суффиксов.
• Ожидаемо: список вида 2026-08-01 51234 KB /var/log/nginx/access.log.15.gz.

Если список устраивает, удаляем:

sudo find /var/log -xdev -type f \( -name '*.gz' -o -name '*.[0-9]' -o -name '*.old' \) -mtime +14 -print -delete

⚠️ Необратимо. -delete удаляет без корзины. Всегда запускайте сначала вариант с -printf/-print, а -delete ставьте в конец выражения: в начале он удалит всё подряд до применения фильтров.

Шаг 3.2. Огромный активный лог Nginx

Если access.log или error.log весит гигабайты, не удаляйте его через rm. Nginx продолжит писать в открытый дескриптор, и место не освободится (см. шаг 2.5).

Вариант А (предпочтительный): принудительная ротация штатным конфигом.

sudo logrotate -f -v /etc/logrotate.d/nginx

• -f ротирует принудительно, даже если по расписанию ещё рано. -v включает подробный вывод.
• После ротации logrotate выполнит postrotate. Nginx получит сигнал USR1 и переоткроет логи без перезапуска и без обрывов соединений.
• Ожидаемо: строки rotating log /var/log/nginx/access.log… и running postrotate script.
• ⚠️ При delaycompress свежая копия access.log.1 остаётся несжатой. Место освободится после следующей ротации, либо удалите или сожмите её вручную.

Вариант Б (экстренный): обнулить файл на месте.

sudo truncate -s 0 /var/log/nginx/access.log

• truncate -s 0 обрезает файл до нуля байт. Дескриптор у Nginx остаётся валидным, место освобождается сразу.
• ⚠️ Необратимо: содержимое лога теряется. Если логи нужны, сначала сохраните сжатую копию на другой носитель, например sudo gzip -c /var/log/nginx/access.log > /mnt/backup/access-$(date +%F).log.gz.

Шаг 3.3. Логи PostgreSQL

Сначала смотрим размеры:

sudo ls -lh /var/log/postgresql/
sudo ls -lh /var/lib/postgresql/14/main/log/ 2>/dev/null

• Логи в /var/log/postgresql/ (стандарт Ubuntu, logging_collector = off): старые *.gz/*.1 уже удалены на шаге 3.1. Активный файл можно обрезать через truncate, как в варианте Б.
• Логи в 14/main/log/ (logging_collector = on): удалять можно только файлы логов в подкаталоге log/, и только старые:

sudo find /var/lib/postgresql/14/main/log -maxdepth 1 -type f -name 'postgresql-*.log' -mtime +7 -print
# после проверки списка — то же самое с -delete вместо -print

• -maxdepth 1 не даёт find уйти глубже каталога log/.
• ⚠️ Проверьте путь дважды. Опечатка вида /var/lib/postgresql/14/main -name ... удалит файлы БД.

Шаг 3.4. Освободить место, занятое «удалёнными» файлами

Если на шаге 2.5 нашлись файлы (deleted):

sudo systemctl reload nginx          # nginx переоткроет логи, мягкая операция
sudo -u postgres psql -X -c "SELECT pg_rotate_logfile();"   # только при logging_collector = on

• reload перечитывает конфиг и переоткрывает логи без обрыва текущих соединений. Не используйте restart без необходимости. Перед reload можно проверить конфиг: sudo nginx -t.
• Для других процессов обычно помогает перезапуск соответствующей службы. Делайте его в согласованное окно.

Шаг 3.5. Если разросся pg_wal

• Неактивный слот репликации. Если реплика точно больше не нужна, удалите слот. Это необратимо: реплика, использовавшая слот, потеряет возможность догнать мастера.

  sudo -u postgres psql -X -c "SELECT pg_drop_replication_slot('ИМЯ_СЛОТА');"
  

• Падает archive_command. Смотрите причину в логе PostgreSQL: grep -i archive /var/log/postgresql/postgresql-14-main.log | tail. Чините команду (часто переполнено место назначения или нет прав).
• В обоих случаях PostgreSQL сам удалит лишние WAL после ближайшего checkpoint. Ускорить можно так: sudo -u postgres psql -X -c "CHECKPOINT;".

4. Настройка ротации, чтобы проблема не повторилась

Шаг 4.1. Проверить, работает ли logrotate вообще

systemctl list-timers logrotate.timer
sudo journalctl -u logrotate.service --since "7 days ago" --no-pager | tail -30
sudo grep -E 'nginx|postgresql' /var/lib/logrotate/status

• Ожидаемо:
  • таймер активен, следующий запуск в ближайшие сутки;
  • в журнале нет строк error:;
  • в state-файле есть свежие даты для логов Nginx и PostgreSQL.
• Если дат нет или они старые, ротация не происходила. Причины разобраны в разделе 6.

Шаг 4.2. Бэкап конфигов

sudo cp -a /etc/logrotate.d/nginx /etc/logrotate.d/nginx.bak-$(date +%F)
sudo cp -a /etc/logrotate.d/postgresql-common /etc/logrotate.d/postgresql-common.bak-$(date +%F)

• cp -a сохраняет права, владельца и время изменения.
• ⚠️ Важно: logrotate читает все файлы в /etc/logrotate.d/, включая бэкапы. Это вызовет ошибку duplicate log entry. Сразу перенесите бэкапы в другое место:

sudo mkdir -p /root/logrotate-backup
sudo mv /etc/logrotate.d/*.bak-* /root/logrotate-backup/

Шаг 4.3. Конфиг для Nginx

sudo nano /etc/logrotate.d/nginx

/var/log/nginx/*.log {
    daily
    maxsize 200M
    rotate 14
    missingok
    notifempty
    compress
    delaycompress
    create 0640 www-data adm
    sharedscripts
    prerotate
        if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
            run-parts /etc/logrotate.d/httpd-prerotate; \
        fi \
    endscript
    postrotate
        invoke-rc.d nginx rotate >/dev/null 2>&1
    endscript
}

Что изменилось относительно стандартного конфига Ubuntu: добавлен maxsize 200M, rotate выставлен в 14.

Директивы:

• daily — ротировать раз в сутки.
• maxsize 200M — ротировать и раньше, если файл превысил 200 МБ. Работает только при запуске logrotate чаще раза в сутки (шаг 4.5).
• rotate 14 — хранить 14 архивов, более старые удаляются автоматически.
• compress / delaycompress — сжимать gzip, но самую свежую копию (.1) оставлять несжатой, пока Nginx гарантированно в неё не пишет.
• create 0640 www-data adm — права и владелец нового файла.
• sharedscripts — выполнить postrotate один раз на все файлы, а не на каждый.
• postrotate … invoke-rc.d nginx rotate — отправить Nginx сигнал USR1 на переоткрытие логов.

⚠️ Если в nginx.conf логи пишутся в подкаталоги (/var/log/nginx/site1/access.log) или вообще вне /var/log/nginx, маска *.log их не охватит. Проверьте фактические пути:

sudo nginx -T 2>/dev/null | grep -E '^\s*(access|error)_log' | sort -u

Для таких путей добавьте их в первую строку конфига через пробел, например /var/log/nginx/*.log /var/log/nginx/*/*.log {.

ℹ️ Файл /etc/logrotate.d/nginx принадлежит пакету (conffile). При обновлении nginx apt спросит, оставить вашу версию или взять новую. Выбирайте «оставить» (N).

Шаг 4.4. Конфиг для PostgreSQL

sudo nano /etc/logrotate.d/postgresql-common

/var/log/postgresql/*.log {
    daily
    maxsize 200M
    rotate 7
    copytruncate
    compress
    delaycompress
    notifempty
    missingok
    su root root
}

• copytruncate копирует лог и обрезает оригинал. PostgreSQL без logging_collector не умеет переоткрывать лог по сигналу, поэтому здесь используется именно этот режим. Минус: несколько строк, записанных в момент копирования, могут потеряться. Для логов это допустимо.
• su root root — от чьего имени выполнять ротацию. Без этой директивы logrotate откажется работать с каталогом, если сочтёт его права небезопасными.

Если logging_collector = on. Системный logrotate тут не нужен, ротацией управляет сам PostgreSQL. Настройки в /etc/postgresql/14/main/postgresql.conf:

log_filename = 'postgresql-%a.log'   # имя по дню недели: Mon, Tue, ...
log_rotation_age = 1d
log_rotation_size = 0                # не ротировать по размеру, иначе truncate сотрёт часть дня
log_truncate_on_rotation = on        # перезаписывать файл недельной давности

• Такая схема даёт кольцо из 7 файлов, которое никогда не растёт бесконечно.
• Применение без перезапуска БД: sudo systemctl reload postgresql@14-main. Все четыре параметра применяются по reload (контекст sighup); это можно проверить запросом SELECT name, context FROM pg_settings WHERE name LIKE 'log_%';.

Проверьте и уровень логирования: log_statement = 'all' на проде почти всегда ошибка. Разумный вариант — log_min_duration_statement = 1000, то есть логировать запросы дольше 1 секунды.

Шаг 4.5. Запускать logrotate каждый час (чтобы работал maxsize)

sudo systemctl edit logrotate.timer

В открывшемся редакторе добавьте:

[Timer]
OnCalendar=
OnCalendar=hourly

Затем примените изменения и проверьте расписание:

sudo systemctl daemon-reload
systemctl list-timers logrotate.timer

• Пустая строка OnCalendar= сбрасывает исходное значение daily. Без неё таймеры сложатся.
• daily в самих конфигах по-прежнему означает «не чаще раза в сутки». Почасовой запуск лишь даёт maxsize шанс сработать раньше.
• Ожидаемо: в колонке NEXT стоит время в пределах ближайшего часа.

Шаг 4.6. Ограничить journald

sudo mkdir -p /etc/systemd/journald.conf.d
printf '[Journal]\nSystemMaxUse=300M\nSystemKeepFree=1G\n' | sudo tee /etc/systemd/journald.conf.d/size.conf
sudo systemctl restart systemd-journald

• SystemMaxUse — потолок размера журнала. SystemKeepFree — сколько места journald обязан оставлять свободным.
• sudo tee используется потому, что перенаправление > выполняется оболочкой без sudo. Конструкция sudo echo … > /etc/… упадёт с Permission denied.
• Перезапуск systemd-journald безопасен, сервисы не затрагиваются.

Шаг 4.7. Проверка конфигов

sudo logrotate -d /etc/logrotate.d/nginx
sudo logrotate -d /etc/logrotate.d/postgresql-common

• -d — режим отладки. Ничего не меняет, только показывает, что logrotate сделал бы. Это и есть dry-run для logrotate.
• Ожидаемо: строки considering log /var/log/nginx/access.log, log does not need rotating или log needs rotating, без строк error:.

Затем боевой прогон и проверка Nginx:

sudo logrotate -f -v /etc/logrotate.d/nginx
systemctl status nginx --no-pager
ls -lh /var/log/nginx/

• Ожидаемо: Nginx в состоянии active (running), появился новый пустой или маленький access.log и копия access.log.1.

5. Скрипт: диагностика и очистка с dry-run по умолчанию

Скрипт объединяет шаги 2.4, 2.5, 3.1 и 3.2. Он не трогает /var/lib/postgresql и активные *.log. Без флага --apply ничего не удаляет.

#!/usr/bin/env bash
# clean-logs.sh — безопасная очистка старых логов в /var/log.
# По умолчанию: dry-run (только показывает). Реальное удаление: sudo ./clean-logs.sh --apply
# Настройка через окружение: RETENTION_DAYS=30 JOURNAL_MAX=500M sudo -E ./clean-logs.sh
set -euo pipefail

readonly LOG_DIR="/var/log"
readonly RETENTION_DAYS="${RETENTION_DAYS:-14}"   # удалять архивы старше N суток
readonly JOURNAL_MAX="${JOURNAL_MAX:-200M}"       # целевой размер журнала systemd
APPLY=0

log()  { printf '[%s] %s\n' "$(date +%T)" "$*"; }
die()  { printf 'ОШИБКА: %s\n' "$*" >&2; exit 1; }
usage(){ echo "Использование: $0 [--apply]"; }

trap 'rc=$?; echo "ОШИБКА: строка $LINENO, код возврата $rc" >&2' ERR

for arg in "$@"; do
  case "$arg" in
    --apply)   APPLY=1 ;;
    -h|--help) usage; exit 0 ;;
    *)         usage >&2; exit 2 ;;
  esac
done

[[ $EUID -eq 0 ]] || die "нужны права root: запустите через sudo"
[[ "$RETENTION_DAYS" =~ ^[0-9]+$ ]] || die "RETENTION_DAYS должно быть числом"
[[ -d "$LOG_DIR" ]] || die "каталог $LOG_DIR не найден"

(( APPLY )) && log "РЕЖИМ: УДАЛЕНИЕ" || log "РЕЖИМ: dry-run (ничего не удаляется)"
log "Свободно на /: $(df -h --output=avail / | tail -1 | tr -d ' ')"

# --- 1. Ротированные архивы старше RETENTION_DAYS. Активные *.log не подходят под маски.
FIND_ARGS=( "$LOG_DIR" -xdev -type f
            '(' -name '*.gz' -o -name '*.xz' -o -name '*.[0-9]' -o -name '*.old' ')'
            -mtime "+$RETENTION_DAYS" )

count=$(find "${FIND_ARGS[@]}" -printf '.' | wc -c)
bytes=$(find "${FIND_ARGS[@]}" -printf '%s\n' | awk '{s+=$1} END {print s+0}')
log "Архивов старше ${RETENTION_DAYS} дн.: ${count} шт., $(numfmt --to=iec "$bytes")"

if (( count > 0 )); then
  if (( APPLY )); then
    find "${FIND_ARGS[@]}" -print -delete
  else
    find "${FIND_ARGS[@]}" -printf '  %TY-%Tm-%Td  %10s  %p\n' | sort
  fi
fi

# --- 2. Журнал systemd
log "journald: $(journalctl --disk-usage 2>&1)"
if (( APPLY )); then
  journalctl --vacuum-size="$JOURNAL_MAX"
else
  log "(dry-run) выполнил бы: journalctl --vacuum-size=$JOURNAL_MAX"
fi

# --- 3. Отчёт: удалённые, но открытые файлы (только диагностика, ничего не меняет)
if command -v lsof >/dev/null 2>&1; then
  log "Удалённые, но удерживаемые процессами файлы (>10 МБ):"
  lsof -nP +L1 2>/dev/null | awk 'NR==1 || $7 > 10485760' || true
fi

# --- 4. Отчёт: крупные активные логи (кандидаты на logrotate -f или truncate вручную)
log "Активные логи крупнее 100 МБ:"
find "$LOG_DIR" -xdev -type f -name '*.log' -size +100M -printf '  %10s  %p\n' | sort -n || true

log "Свободно на / после: $(df -h --output=avail / | tail -1 | tr -d ' ')"

Запуск:

chmod +x clean-logs.sh
sudo ./clean-logs.sh            # посмотреть, что будет сделано
sudo ./clean-logs.sh --apply    # выполнить

Пояснения к реализации:

• set -euo pipefail: скрипт завершается при любой ошибке, при обращении к необъявленной переменной и при сбое любой команды в конвейере.
• Аргументы find собраны в массив FIND_ARGS. Поэтому dry-run и удаление гарантированно используют одинаковый фильтр, и не бывает ситуации «проверил одно, удалил другое».
• || true стоит там, где пустой результат — это норма. Например, lsof возвращает код 1, если ничего не нашёл, и без || true это прервало бы скрипт.
• В конвейерах нет head: с pipefail он может вызвать ложное падение из-за SIGPIPE (код 141).

Регулярно запускать скрипт не нужно, эту работу берёт на себя logrotate. Скрипт предназначен для разовой уборки.

6. Устранение неполадок

Общий приём: у любой команды проверяйте код возврата через echo $? сразу после неё. 0 означает успех, всё остальное — повод читать вывод или man.

Полезно знать

1. ncdu — интерактивный анализатор диска (sudo apt install ncdu, затем sudo ncdu -x /var). Показывает то же, что du | sort, но позволяет ходить по каталогам стрелками. Клавиша d удаляет файл, так что будьте внимательны.
2. rm не освобождает место, пока файл открыт. Для активных логов используйте truncate -s 0 или ротацию с переоткрытием. Для внезапных расхождений df/du первым делом запускайте lsof +L1.
3. Мониторинг вместо пожаротушения. Чтобы узнавать о проблеме заранее, а не на 95%, можно повесить в cron простую проверку: df --output=pcent / | tail -1 | tr -dc '0-9' и уведомление при значении выше 80. Ещё лучше — node_exporter + Prometheus или любой внешний мониторинг VPS.
4. Логи Nginx можно писать сразу сжатыми и с буфером: access_log /var/log/nginx/access.log combined gzip=5 buffer=64k flush=5m;. Это снижает объём и нагрузку на диск. Для статики и health-check'ов можно отключить логирование (access_log off; в нужном location). После правки обязательно sudo nginx -t && sudo systemctl reload nginx.