Debian/Ubuntu: как подружить /var/log, logrotate и journald и не забить диск

В Debian/Ubuntu логирование часто выглядит как «зоопарк»: часть событий уходит в systemd-journald, часть — в текстовые файлы в /var/log, а ротацией занимается logrotate. Пока всё работает — это незаметно. Проблемы начинаются, когда диск внезапно заканчивается, логи «пропадают», или выясняется, что архивы сжимаются, а место не возвращается.

Ниже — практический разбор связки /var/log + logrotate + journald + rsyslog: как это устроено, где чаще всего «подтекает» место, и какие настройки дают предсказуемую политику хранения без сюрпризов.

Карта местности: что именно логирует Debian/Ubuntu

Упрощённо есть два мира:

• Текстовые файлы в /var/log: классические auth.log, syslog, логи веб-сервера, БД, приложений.

• Двоичный журнал systemd-journald: доступен через journalctl. Он может храниться только в памяти или на диске (persistent).

Как эти миры пересекаются:

• Сервисы под systemd часто пишут в stdout/stderr, а systemd забирает это в journald.

• rsyslog (если установлен и включён) может забирать сообщения из journald и записывать их в файлы в /var/log (например, в /var/log/syslog).

• logrotate работает только с файлами (включая файлы в /var/log). Он не «ротирует journald».

Быстрая диагностика: кто съел диск — journald или /var/log

1) Сколько места занимает journald

journalctl --disk-usage

Если видите десятки гигабайт — либо нет лимитов journald, либо какой-то сервис генерирует лавину событий (и тогда лучше сначала найти виновника по unit/priority).

2) Сколько места занимает /var/log и какие файлы лидеры

du -sh /var/log
du -h /var/log | sort -h | tail -n 20

Ищите крупные «старые» архивы (.gz, .1, .2) и нестандартные логи приложений, которые могли «жить своей жизнью» вне /etc/logrotate.d.

3) Классическая ловушка: файл удалён, а место не освободилось

Это бывает, когда процесс продолжает писать в уже удалённый файл (дескриптор открыт). В итоге в du файла нет, а в df место занято.

df -h
lsof +L1 | head -n 50

Если видите большие записи с (deleted), нужно перезапустить соответствующий сервис или корректно переоткрыть логи (reopen/reload), иначе занятое место не вернётся.

Как journald хранит логи и почему он может разрастаться

systemd-journald хранит записи в бинарных файлах. Поведение задаётся в /etc/systemd/journald.conf и/или в drop-in файлах /etc/systemd/journald.conf.d/*.conf.

Две настройки, которые дают «потолок» и предсказуемость:

• SystemMaxUse — верхний предел дискового пространства для persistent-журнала.

• SystemKeepFree — сколько свободного места оставлять на файловой системе, чтобы журнал не «дожал» диск до нуля.

Дополнительно часто полезны SystemMaxFileSize (размер одного файла журнала) и MaxRetentionSec (удержание по времени).

Пример практичного профиля для небольшого сервера (идея: ограничить journald по месту, оставить запас по диску и держать историю неделю):

cat /etc/systemd/journald.conf.d/10-retention.conf

[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=500M
SystemMaxFileSize=100M
MaxRetentionSec=7day
Compress=yes

Применяем изменения:

systemctl restart systemd-journald

Проверьте, что журнал действительно persistent (иначе после ребута часть истории исчезнет):

test -d /var/log/journal && echo persistent || echo volatile

Если вам нужна централизованная доставка journald на отдельный лог-сервер, посмотрите настройку удалённого приёма/отправки: systemd-journal-remote: приём и отправка журналов.

Vacuum в journald: быстро подчистить историю

В обиходе часто говорят «vacuum-time» как про действие «удалить старое по времени». В journald это делается командами journalctl:

journalctl --vacuum-time=7d
journalctl --vacuum-size=1G
journalctl --vacuum-files=20

Vacuum — это разовая уборка. Чтобы проблема не возвращалась, важнее выставить лимиты SystemMaxUse и (по ситуации) MaxRetentionSec.

Почему journald растёт, даже если вы «всё ротируете logrotate»

Потому что logrotate вообще не управляет journald: он работает только с файловыми логами. Если сервисы пишут в journald (по умолчанию), и при этом rsyslog сохраняет те же события в /var/log/syslog, вы можете хранить одни и те же события дважды (и расходовать место вдвойне).

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

rsyslog: нужен ли он вообще и как не хранить дубликаты

В Debian/Ubuntu часто установлен rsyslog, который делает «традиционные» файлы /var/log/syslog, /var/log/auth.log и т.д. В эпоху systemd это выбор: хранить только journald или вести ещё и файловый syslog.

Когда rsyslog полезен:

• Нужно отправлять логи во внешнюю систему (SIEM/коллектор) привычным syslog-способом.

• Есть инструменты/скрипты, завязанные на конкретные файлы в /var/log.

• Нужно разделять каналы/facility по разным файлам (операционно иногда удобнее).

Когда rsyslog можно не держать:

• Логи смотрите через journalctl, и journald для вас — источник истины.

• Хотите минимизировать запись на диск (актуально для небольших SSD) и избавиться от дублей.

Проверка состояния:

systemctl is-enabled rsyslog
systemctl status rsyslog --no-pager

Если решите отключать rsyslog, делайте это осознанно: сначала убедитесь, что journald у вас persistent и ограничен по размеру, иначе можно потерять привычную «историю» при перезагрузке.

logrotate: как устроена ротация в /var/log и где обычно ломается

logrotate запускается по таймеру systemd или через cron (зависит от дистрибутива/версии). Он берёт правила из /etc/logrotate.conf и /etc/logrotate.d/* и делает ротацию: переименование, сжатие, хранение нескольких поколений.

Посмотреть, когда он запускается:

systemctl list-timers | grep -E 'logrotate|daily' || true

Ручной прогон (без реальных изменений) для диагностики:

logrotate -d /etc/logrotate.conf

Принудительный прогон:

logrotate -f /etc/logrotate.conf

Параметры, которые важно понимать

• rotate N — сколько поколений хранить.

• daily/weekly/monthly — период.

• size — ротация по достижению размера.

• compress/delaycompress — сжатие (с задержкой на одно поколение или без).

• missingok, notifempty — не ругаться на отсутствие/пустоту.

• create — создать новый файл с правами/владельцем.

• postrotate — команда после ротации (часто: попросить сервис переоткрыть лог).

• copytruncate — копировать и обнулить текущий файл без сигнала приложению.

copytruncate: когда помогает, а когда делает хуже

copytruncate популярен, когда приложение не умеет reopen логов. Он «обходит» проблему открытого дескриптора: копирует текущий файл в ротированный и затем обнуляет оригинал.

Минусы подхода:

• На очень активных логах возможна потеря строк (если пишут в момент копирования).

• Это дополнительный IO: копирование больших файлов может быть дорогим.

Если сервис умеет reopen, лучше использовать postrotate с reload/сигналом (например, USR1 или штатный reload), чтобы приложение само переоткрыло файл и продолжило писать уже в новый.

Практические профили: «маленький диск», «много логов», «важен аудит»

Профиль 1: маленький диск (VPS/VDS), хотим предсказуемый потолок

Цель: journald ограничить жёстко, файловые логи в /var/log — ротировать по размеру и хранить недолго. Такой профиль особенно уместен на небольших серверах, где root-раздел легко забить логами.

Journald (пример):

[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=500M
MaxRetentionSec=7day

Logrotate для «болезненных» логов (пример подхода, не универсальный шаблон):

cat /etc/logrotate.d/app-size-based

/var/log/myapp/*.log {
  size 100M
  rotate 10
  compress
  delaycompress
  missingok
  notifempty
  create 0640 root adm
}

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

Профиль 2: много логов, но важно быстро искать

Часто удобнее держать journald как основной источник (поиск, фильтры по unit/boot/priority), а файловые логи оставить только там, где они реально нужны (например, access/error у веб-сервера).

Полезные команды для поиска:

journalctl -u nginx --since today
journalctl -p warning..emerg --since -1h
journalctl --since -10m -o short-iso

Профиль 3: важен аудит (auth, sudo, ssh), хранение дольше

Для аудита обычно нужно: (1) persistence; (2) понятная политика retention; (3) защита от переполнения диска; (4) аккуратная ротация файлов auth.log (если используете rsyslog).

Проверьте, где у вас живут события SSH/sudo: в journald, в /var/log/auth.log, или в обоих местах. Затем задайте retention так, чтобы журнал не выдавливал критически важные записи слишком быстро.

Если интересуют практики мониторинга входов и тревог по SSH, можно дополнить схему алертами: уведомления о SSH-логинах через PAM и journald.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Типовые проблемы и быстрые решения

Проблема: journald занимает много, а в конфиге всё ограничено

Проверьте:

• Есть ли переопределения в /etc/systemd/journald.conf.d/ (drop-in файлы имеют приоритет).

• Не ограничили ли вы только RuntimeMaxUse (это про журнал в памяти), а persistent-журнал на диске оставили без лимита.

• Журнал действительно persistent: каталог /var/log/journal существует.

После правок перезапускайте journald:

systemctl restart systemd-journald

Проблема: rotated logs есть, а места не стало больше

Самые частые причины:

• Дескриптор открыт в удалённый файл (проверяйте lsof +L1).

• Ротация настроена, но rotate слишком большой и/или нет maxage (архивы копятся годами).

• Сжимается не всё: где-то нет compress, или большие логи пишутся в каталог, который не покрыт правилами.

Проблема: logrotate «не ротирует» конкретный лог

Проверьте права и владельца файла/каталога, а также директиву su в правилах (актуально для некоторых сервисов). Посмотрите, что говорит debug-режим:

logrotate -d /etc/logrotate.conf 2>&1 | tail -n 200

Как выбрать стратегию хранения: короткий чек-лист

1. Решите, кто «источник истины»: journald, файлы в /var/log, или оба (но тогда учитывайте дубли).

2. Поставьте предел journald через SystemMaxUse и резерв свободного места через SystemKeepFree.

3. Для файловых логов используйте logrotate с ротацией по времени или по размеру (часто лучше по размеру для «всплесков»).

4. Убедитесь, что сервисы корректно переоткрывают логи после ротации (через reload/USR1), и не злоупотребляйте copytruncate.

5. Периодически проверяйте: journalctl --disk-usage, топ файлов в /var/log, и lsof +L1 при странных «утечках» места.

Мини-справочник команд (на каждый день)

journalctl --disk-usage
journalctl --vacuum-time=7d
journalctl -u ssh --since -2h

du -sh /var/log
du -h /var/log | sort -h | tail -n 20

logrotate -d /etc/logrotate.conf
logrotate -f /etc/logrotate.conf

lsof +L1 | head

Если привести journald и logrotate к понятным лимитам и убрать дублирование через rsyslog там, где оно не нужно, проблема «внезапно забился диск из-за логов» обычно исчезает надолго — а логи остаются управляемыми и предсказуемыми.