VDS: как навести порядок в логах с journald, syslog и logrotate

На свежем VDS логи почти всегда устроены по принципу «как сделали в дистрибутиве». Что‑то уходит в journald, что‑то в /var/log/*.log, часть сервисов пишет свои файлы и к ним кое‑как привинчен logrotate. Пока трафика мало, это терпимо. Но как только проект вырастает, начинаются проблемы:

• диски забиваются гигабайтами логов;

• нужный лог искать сложно — часть в journalctl, часть в файлах;

• ротация работает не так, как вы ожидали: что‑то крутится по размеру, что‑то раз в неделю, а что‑то не крутится вообще.

Разберёмся, как навести порядок в логах на арендованном VDS, где у нас под рукой journald, классический syslog (rsyslog/syslog-ng) и logrotate. Цель — понятная схема, предсказуемая ротация и защита диска от переполнения.

Что сейчас пишет логи на вашем VDS

Для начала нужно понять, кто вообще занимается логированием на вашем сервере. На современных Debian/Ubuntu/CentOS/Rocky/Alma Linux обычно присутствуют:

• systemd-journald — собирает логи всех юнитов systemd, ядра, иногда демонов syslog.
• rsyslog или syslog-ng — классический syslog‑демон, пишет в /var/log/messages, /var/log/syslog, /var/log/auth.log и т.п.
• logrotate — отдельный инструмент ротации файлов логов по расписанию (обычно запускается cron’ом или systemd‑таймером каждую ночь).

Ещё есть отдельные приложения (nginx, PHP‑FPM, PostgreSQL, Redis и т.п.), которые могут логировать либо напрямую в файлы, либо в syslog, либо вообще в stdout/stderr (особенно в Docker‑окружениях).

Проверяем, используется ли journald и rsyslog

Команды для диагностики:

systemctl status systemd-journald
systemctl status rsyslog
systemctl status syslog-ng

Если запущены и systemd-journald, и rsyslog, значит логирование как минимум двухуровневое: journald принимает сообщения, а rsyslog читает их из сокета journald и складывает в файлы.

Чтобы понять, какой объём занимают файлы логов, можно воспользоваться du:

du -sh /var/log

А для самого journald:

journalctl --disk-usage

Journald против syslog: во что писать?

Практический вопрос: стоит ли «пересаживать» всё на journald или продолжать использовать классический syslog и файлы + logrotate?

Плюсы journald

• Структурированные записи: метки юнита, PID, UID, cgroup, поля для контейнеров.
• Удобный фильтр по systemd-юнитам: journalctl -u nginx.service.
• Центральное место сбора логов большинства сервисов.
• Ротация по размеру и времени встроена — не нужен logrotate для бинарного журнала.

Минусы journald

• Формат бинарный — не всегда удобно для сторонних тулов, которые ждут текстовые файлы.
• По умолчанию может храниться в /run/log/journal (tmpfs) только в памяти, и логи пропадут после перезагрузки (зависит от дистрибутива).
• Некоторые приложения до сих пор проще настраивать на вывод в файл или в syslog, чем в journald.

Роль классического syslog (rsyslog/syslog-ng)

Syslog решает две задачи:

• Разбрасывает логи по традиционным файлам типа /var/log/auth.log, /var/log/maillog и т.д.
• Может пересылать логи на удалённый лог‑сервер (централизованный сбор).

На большинстве VDS разумная схема такая:

Journald — основное место приёма логов systemd‑юнитов и ядра. Rsyslog забирает от него события и пишет в привычные текстовые файлы, которые затем крутит logrotate.

Это даёт и удобство journalctl, и привычные файлы вида /var/log/nginx/access.log, и предсказуемую ротацию.

Настройка journald: сколько логов хранить

По умолчанию journald может вести себя не совсем так, как вы ожидаете: где‑то он пишет в оперативную память только текущий журнал, где‑то заводит персистентный каталог в /var/log/journal и забивает диск.

Включаем постоянное хранение или наоборот ограничиваем

Конфиг journald: /etc/systemd/journald.conf. Там есть параметры:

• Storage= — auto, volatile, persistent, none.
• SystemMaxUse= — общий максимум места, которое journald может занять.
• SystemKeepFree= — сколько места оставлять на диске свободным.
• SystemMaxFileSize= — максимальный размер одного файла журнала.
• MaxRetentionSec= — максимальный срок хранения записей.

Пример базовой настройки для VDS с диском 40–80 ГБ:

[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=2G
SystemMaxFileSize=256M
MaxRetentionSec=14day
Compress=yes

После изменения конфига перезапустите journald:

systemctl restart systemd-journald

Теперь journald:

• будет хранить журналы в /var/log/journal;
• не займёт больше 1G места;
• не будет съедать последние 2 ГБ на диске;
• будет автоматически подрезать журналы старше 14 дней.

Syslog и текстовые логи: что именно крутит logrotate

Чтобы не получить сюрпризы, нужно разобраться, какие лог‑файлы реально подпадают под ротацию, а какие живут своей жизнью.

Где смотреть конфиги logrotate

Основной конфиг:

• /etc/logrotate.conf — общие параметры.
• /etc/logrotate.d/ — отдельные файлы для разных сервисов: nginx, rsyslog, mysql, php* и т.п.

Посмотреть, как запускается logrotate по расписанию:

systemctl status logrotate.timer

Либо через cron (в старых системах):

cat /etc/cron.daily/logrotate

Типичный фрагмент конфига logrotate для Nginx

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 640 www-data adm
    sharedscripts
    postrotate
        [ -s /run/nginx.pid ] && kill -USR1 $(cat /run/nginx.pid)
    endscript
}

Ключевые параметры:

• daily — ротация раз в день.
• rotate 14 — хранить 14 архивов (2 недели).
• compress + delaycompress — сжатие архивов .gz, но не сразу, а со следующего цикла.
• notifempty — не трогать пустые файлы.
• create — пересоздать файл с нужными правами после ротации.
• postrotate ... endscript — команда, чтобы nginx открыл новые файлы логов (сигнал USR1).

Ротация по размеру вместо по времени

Если у вас нагруженный VDS, имеет смысл крутить логи не раз в день, а как только файл достигнет определённого размера (size):

/var/log/nginx/access.log {
    size 100M
    rotate 10
    compress
    missingok
    notifempty
    create 640 www-data adm
    sharedscripts
    postrotate
        [ -s /run/nginx.pid ] && kill -USR1 $(cat /run/nginx.pid)
    endscript
}

Так вы избежите ситуации, когда один лог‑файл разрастается до десятков гигабайт за день и забивает диск до того, как сработает daily.

Связка journald + rsyslog + logrotate

На многих системах rsyslog по умолчанию получает сообщения из journald и раскладывает их в файлы. Это задаётся в конфиге rsyslog (например, /etc/rsyslog.conf или отдельном инклюде).

Проверяем источник логов rsyslog

Ищите строки вида:

module(load="imuxsock")
module(load="imjournal" StateFile="imjournal.state")

Модуль imjournal как раз читает журналы из journald. Вместо него может использоваться старый модуль imuxsock, тогда rsyslog читает напрямую из сокета /run/systemd/journal/syslog.

Важно понимать: даже если journald уже ограничивает объём логов, файлы, которые создаёт rsyslog, всё равно могут разрастаться. Ими занимается только logrotate.

Минимальный чек‑лист для связки

• Journald ограничен по диску (SystemMaxUse, SystemKeepFree).
• Все крупные сервисы (nginx, PHP‑FPM, базы данных) либо пишут в syslog (а тот — в файлы), либо напрямую в файлы в /var/log.
• Для каждого такого файла есть конфиг в /etc/logrotate.d/.
• logrotate реально запускается systemd-таймером или cron’ом и не выдаёт ошибок.

Типовые проблемы логов на VDS и как их чинить

1. «Диск внезапно забился логами»

Алгоритм анализа:

1. Смотрим, что именно заняло место:

du -h /var/log --max-depth=1 | sort -h

2. Если виноват journald:

journalctl --disk-usage

Правим /etc/systemd/journald.conf, уменьшаем SystemMaxUse и/или MaxRetentionSec, потом форсируем очистку:

journalctl --vacuum-size=500M

3. Если это один из файлов логов (например, /var/log/nginx/access.log):

• убедитесь, что для него есть конфиг в /etc/logrotate.d/nginx;
• если ротация есть, но файл всё равно огромный, возможно, logrotate не запускается или падает с ошибкой;
• временно можно вручную ротировать файл (аккуратно):

mv /var/log/nginx/access.log /var/log/nginx/access.log.manual-$(date +%s)
kill -USR1 $(cat /run/nginx.pid)

После этого nginx начнёт писать в новый файл.

2. «Логи есть в journalctl, но нет в файлах»

Частая ситуация на минималистичных установках: journald включён, а rsyslog нет. Тогда:

• Логи есть в journalctl, но нет привычных /var/log/syslog, /var/log/messages и т.п.
• Многие тулзы и скрипты, ожидающие файлы, перестают работать.

Варианта два:

1. Смириться и использовать только journald. Тогда надо:

• настроить journalctl-алиасы, фильтры (-u, -p, --since, --grep);
• проверить настройки ротации journald, как описано выше;
• по возможности перевести свои скрипты на работу с journalctl вместо grep’а по файлам.

2. Поставить и настроить rsyslog (или syslog-ng), чтобы писать в файлы.

Обычно на VDS удобнее второй путь: journalctl для быстрой диагностики + файлы для долгосрочного хранения и интеграции с другими тулзами. Для централизованного сбора логов можно рассмотреть отдельный лог‑сервер или связку с приёмником, как в сценариях из статьи о настройке удалённого сбора логов через systemd-journal-remote.

3. «Logrotate не перезапускает сервис после ротации»

Критично для nginx, PHP‑FPM, приложений, которые открывают файлы логов при старте. Если после ротации не послать им сигнал, они продолжат писать в старый (уже переименованный) файл, а новый останется пустым.

Проверьте блок postrotate ... endscript в конфиге logrotate для нужного сервиса. Например, для PHP‑FPM:

/var/log/php8.2-fpm.log {
    weekly
    rotate 12
    compress
    missingok
    notifempty
    create 640 www-data adm
    postrotate
        [ -x /usr/sbin/service ] && service php8.2-fpm reload
    endscript
}

Если вы меняли путь к PID‑файлу или имя сервиса, адаптируйте команду перезапуска.

Практический чек‑лист по логам для небольшого/среднего VDS

Соберём всё в один список, чтобы можно было пройтись по нему при настройке нового сервера или после миграции проекта на новый VDS (подобно шагам из гайда по миграции сайтов без простоя).

1. Настройка journald

• Убедиться, что Storage=persistent, если нужны логи после перезагрузки.
• Выставить разумные SystemMaxUse, SystemKeepFree и MaxRetentionSec.
• Проверить текущее использование: journalctl --disk-usage.

2. Определиться, нужен ли rsyslog

• Если вы планируете отправлять логи на внешний сервер — rsyslog/syslog-ng почти наверняка нужны.
• Если у вас много легаси‑скриптов, читающих /var/log/syslog, лучше оставить rsyslog.
• Если хотите минимализм — можно жить и на чистом journald, но тогда забудьте про logrotate для системных логов (он их не трогает).

3. Инвентаризация файлов логов

• Пробежаться по /var/log, выписать крупные и активные файлы: access.log, error.log, php-fpm.log, mysqld.log, postgresql-*.log.
• Проверить, есть ли для каждого из них конфиг в /etc/logrotate.d/.
• Если нет — дописать.

4. Настроить ротацию по размеру для шумных логов

Например, access‑логи nginx с высоким трафиком:

• size 50M–100M вместо daily.
• rotate 7–14, чтобы не хранить месяцы подробной истории, если это не нужно по нормам учёта.
• compress всегда включать, это заметно экономит дисковое пространство.

5. Проверить запуск logrotate

• При использовании systemd‑таймера: systemctl list-timers | grep logrotate.
• В логах systemd: journalctl -u logrotate.
• При использовании cron: убедиться, что /etc/cron.daily/logrotate существует и исполняется.

Полезно один раз прогнать logrotate в тестовом режиме:

logrotate -d /etc/logrotate.conf

Ключ -d означает «dry run» — покажет, что он собирается сделать, но ничего не изменит.

Syslog, journald и безопасность

Логи — чувствительная информация: IP‑адреса, заголовки запросов, иногда фрагменты запросов/ответов, технические сообщения об ошибках.

Минимизируем лишнее в логах

• В access‑логах nginx отключать или маскировать чувствительные URI, query‑параметры (пароли, токены) — через кастомный log_format и map в конфиге.
• В приложении не логировать сырые пароли, токены, персональные данные.
• Понизить уровень логирования для сервисов, которые по умолчанию слишком многословны (например, включён debug).

Доступ к логам

• Права на файлы логов — только для нужных пользователей/групп (0600 или 0640), особенно для auth‑логов, почтовых логов и логов приложений.
• Если даёте доступ разработчикам на VDS, продумайте, нужны ли им логи БД или системные логи авторизации. Для уведомлений о подозрительных логинах можно дополнительно использовать сценарии наподобие разбора auth‑логов из статьи о уведомлениях о входах по SSH.

Мониторинг и алерты по логам без тяжёлых стеков

Даже если вы не поднимаете полный стек уровня ELK/Loki, полезно иметь минимум:

• Мониторинг свободного места на дисках и именно каталога /var/log.
• Алерты по ключевым ошибкам в логах (например, 5xx в nginx, критические ошибки в приложении).

Быстрые варианты без сложных систем

• Простые скрипты, которые раз в N минут проверяют размер логов и отправляют уведомление (почта, мессенджер) при превышении.
• Использование journalctl -p err и фильтров по юнитам для регулярной выборки критичных сообщений.
• Интеграция rsyslog с удалённым приёмником логов, где уже настроены алерты.

Итог: рабочая стратегия логирования для VDS

Задача не в том, чтобы выбрать один «правильный» инструмент (journald или syslog), а в том, чтобы связать их в понятную и предсказуемую схему.

Универсальный вариант для небольшого и среднего VDS:

• Journald — точка входа для системных логов и большинства сервисов, настроенная на ограничение места на диске и адекватный срок хранения.
• Rsyslog/syslog-ng — собирает системные сообщения (из journald или напрямую) и пишет в аккуратные файлы, по которым легко искать, парсить и отправлять наружу.
• Logrotate — крутит текстовые логи по размеру и/или по времени, с запасом ротированных копий и сжатием.
• Приложения — либо пишут в syslog, либо в свои файлы, для которых обязательно есть конфиги logrotate и команды перезапуска/перечитывания после ротации.

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