Что такое ротация логов (log rotation)

Ротация логов — это процесс периодического переименования/перемещения/архивации и очистки файлов журналов, чтобы контролировать их размер, количество и время хранения. Цель — не допустить переполнения диска, уменьшить стоимость хранения и упростить работу с логами (поиск, архивирование, удаление старых записей).

Зачем нужна ротация

• логи растут бесконечно → занимают весь диск и падают сервисы;

• удобство работы — меньшие файлы читаются и индексируются быстрее;

• соответствие требованиям хранения и приватности (ретеншн);

• контроль затрат на индексацию/хранение;

• возможность архивировать и сжимать старые логи.

Как работает ротация — основные триггеры и действия

Триггеры:

• по размеру (например, >100M),

• по времени (daily, weekly, monthly),

• по возрасту (старше N дней),

• по числу ротаций (keep N copies).

Действия при ротации:

• rename (move) текущего файла в файл с суффиксом (например access.log → access.log.1 или access.log-2025-08-12), затем создать новый пустой файл;

• copytruncate — скопировать содержимое и затем усечь (truncate) исходный файл (используется, когда приложение не умеет перекрывать файл);

• compress — сжать старые файлы (gzip/bzip2);

• delaycompress — сжимать начиная со 2-й ротации (оставить последний незжатым для быстрого доступа);

• olddir — переместить старые файлы в отдельную папку;

• postrotate / prerotate — команды, выполняемые до/после ротации (например, послать SIGHUP приложению, чтобы оно открыл новый дескриптор).

Инструменты

• logrotate (Linux) — стандартный демон для file-based логов; конфигурации /etc/logrotate.conf и /etc/logrotate.d/*.

• rotatelogs (Apache) — библиотека/утилита для ротации.

• systemd-journald — имеет собственные ограничения (SystemMaxUse, MaxFileSec).

• лог-агрегаторы/шипперы (Fluentd, Fluent Bit, Filebeat, Vector) — часто решают ротацию на уровне отправки (шлют логи в централизованное хранилище, где ретеншн управляется централизовано).

• В контейнерах рекомендуется писать в stdout/stderr и полагаться на лог-драйвер (docker json-file с max-size/max-file) или на централизованный сборщик, а не на локальную ротацию файлов.

Важные нюансы и подводные камни

• copytruncate безопасно, но теряет atomicity: в короткий момент есть риск дублирования или пропуска строк; более надёжно использовать rename + создание нового файла и сигнализацию процесса.

• Если приложение держит open file descriptor на старом inode, то простое переименование не освободит диск — файл продолжит занимать место, пока процесс не закроет дескриптор. В таком случае нужно либо перезаписать дескриптор (SIGHUP/reopen), либо restart/реинициализация логгера.

• Неправильные права/владельцы нового файла → приложение не сможет писать. В logrotate используйте директиву create mode owner group.

• Сжатие экономит место, но повышает CPU при архивации/распаковке; задержка сжатия (delaycompress) полезна для последних логов.

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

Пример конфигурации logrotate

/var/log/myapp/\*.log {
daily
rotate 14
size 100M
compress
delaycompress
missingok
notifempty
copytruncate
create 0640 myuser adm
postrotate
systemctl kill -s HUP myapp.service >/dev/null 2>&1 || true
endscript
}

Лучшие практики

• писaть структурированные логи и использовать correlation_id;

• если возможно — логировать в stdout и использовать централизованный шиппер;

• при file-based логах — prefer rename + сигнал процессу (не copytruncate);

• задавать разумный retention и проверять free disk space;

• мониторить метрики ротации: возраст старейшего лога, число файлов, свободное место;

• автоматизировать проверку успешности postrotate-скриптов и отслеживать ошибки ротации в отдельный лог.

Ротация логов — не только админская утилита, а часть стратегии наблюдаемости и управления инцидентами: без неё рост логов быстро приведёт к operational-проблемам и усложнит расследование.