Постоянный журнал и ротация логов

Volatile vs persistent: где живёт журнал?

journald хранит записи в одном из двух мест в зависимости от конфигурации:

# Проверить, где сейчас живёт журнал:
ls /run/log/journal/   # volatile — теряется при перезагрузке (tmpfs)
ls /var/log/journal/   # persistent — переживает перезагрузку

# Проверить использование диска:
journalctl --disk-usage
# Archived Journals: 0 B
# Active Journals: 48.0 M

# На системе только с volatile-хранилищем:
# /var/log/journal/ НЕ существует
# Все данные в /run/log/journal/ (tmpfs, теряется при перезагрузке)

# Проверить текущую настройку Storage:
grep -i storage /etc/systemd/journald.conf 2>/dev/null || \
  grep -i storage /etc/systemd/journald.conf.d/*.conf 2>/dev/null || \
  echo "Storage= не задан — умолчание auto"

Умолчание Storage=auto означает: использовать persistent, если /var/log/journal/ уже существует, иначе — volatile. На свежей установке Ubuntu /var/log/journal/ обычно не существует, поэтому по умолчанию ты в режиме volatile.

Включить постоянное хранилище.

Одна строка в journald.conf и создание директории:

# Создать конфигурационный drop-in:
sudo mkdir -p /etc/systemd/journald.conf.d/
sudo tee /etc/systemd/journald.conf.d/persistence.conf <<'EOF'
[Journal]
Storage=persistent
EOF

# Создать директорию постоянного хранилища:
sudo mkdir -p /var/log/journal

# Применить изменение (перезагрузка не нужна):
sudo systemctl restart systemd-journald

# Проверить:
journalctl --disk-usage
# Archived Journals: 0 B
# Active Journals: 52.0 M  ← теперь на диске в /var/log/journal/

ls /var/log/journal/
# <machine-id>/  ← одна директория на machine ID

После включения постоянности логи следующей и всех последующих загрузок переживают перезагрузки. Логи до изменения ретроактивно не сохраняются.

Ограничение размера журнала через SystemMaxUse.

Без ограничения размера постоянный журнал будет расти, пока не заполнит диск. У journald есть встроенные умолчания (10% файловой системы или 4 ГБ, что меньше), но на небольшом VPS это умолчание всё равно может съесть критическое место.

# Задать явные ограничения размера в drop-in:
sudo tee /etc/systemd/journald.conf.d/size.conf <<'EOF'
[Journal]
SystemMaxUse=500M
SystemKeepFree=200M
RuntimeMaxUse=100M
EOF

# SystemMaxUse      — максимум диска для журнала
# SystemKeepFree    — всегда держать столько свободным на разделе
# RuntimeMaxUse     — ограничение для volatile-журнала (/run)

sudo systemctl restart systemd-journald

# Проверить использование после перезапуска:
journalctl --disk-usage
# Archived Journals: 320.1 M
# Active Journals: 48.0 M
# Total: 368.1 M  ← в пределах лимита 500M

journald соблюдает лимит, ротируя и удаляя самые старые архивные файлы журнала. Команды очистки вручную не нужны — соблюдение непрерывное.

Ручная очистка: обрезать данные журнала по требованию.

Когда нужно немедленно освободить место (например, после шторма логов), используй --vacuum-size или --vacuum-time:

# Удалить архивные журналы до суммарного размера 200M:
sudo journalctl --vacuum-size=200M
# Vacuuming done, freed 148.3M of archived journals

# Удалить журналы старше 2 недель:
sudo journalctl --vacuum-time=2weeks

# Удалить журналы старше 30 дней:
sudo journalctl --vacuum-time=30d

# Комбинировать (применяется более строгое):
sudo journalctl --vacuum-size=500M --vacuum-time=30d

# Проверить место после очистки:
journalctl --disk-usage

Vacuum удаляет только архивные (сротированные) журналы, никогда — активный. Безопасно запускать на живой системе. Типичный паттерн: запускать --vacuum-time=30d еженедельно через systemd timer или cron.

logrotate для текстовых логов в /var/log.

Не всё идёт через journald. Приложения вроде nginx, PostgreSQL и многие унаследованные демоны всё ещё пишут в файлы под /var/log. Ими управляет logrotate.

# logrotate управляется через /etc/logrotate.conf и /etc/logrotate.d/:
cat /etc/logrotate.d/nginx
# /var/log/nginx/*.log {
#   daily
#   missingok
#   rotate 14
#   compress
#   delaycompress
#   notifempty
#   create 0640 www-data adm
#   sharedscripts
#   postrotate
#     /bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true
#   endscript
# }

# Ключевые директивы:
# daily/weekly/monthly   — частота ротации
# rotate 14              — хранить 14 сротированных файлов, затем удалять
# compress               — gzip сротированных файлов (экономит ~90% места)
# delaycompress          — не сжимать самый последний сротированный файл
#                           (nginx может ещё писать в него)
# postrotate/endscript   — выполнить этот блок после ротации
#                           (посылает USR1 nginx для переоткрытия лог-файлов)

# Тестировать logrotate без реального выполнения (dry run):
sudo logrotate --debug /etc/logrotate.d/nginx

# Принудительно выполнить ротацию немедленно:
sudo logrotate --force /etc/logrotate.d/nginx

Блок postrotate критически важен: приложения, держащие дескриптор открытым, продолжают писать в старый (переименованный) файл даже после того, как logrotate его переместил. Отправка USR1 (или перезагрузка сервиса) говорит приложению закрыть и переоткрыть дескриптор лог-файла — и оно начинает писать в новый пустой файл.