engineer@northline:~$ less articles/log-retention.md

Log retention on quiet hostsХранение логов на спокойных хостах

Small hosts rarely need a complex logging pipeline, but they do need retention that matches disk size and troubleshooting habits. My default goal is simple: keep enough local history to diagnose the last incident without letting logs crowd out application data.Небольшим хостам редко нужен сложный logging pipeline, но им точно нужна политика хранения логов, соразмерная диску и привычкам диагностики. Моя стандартная цель проста: держать достаточно локальной истории, чтобы разобрать последний инцидент, но не позволять логам вытеснять данные приложений.

Practical baselineПрактический baseline

• Rotate logs on size and age, not on age alone.Ротировать логи и по размеру, и по возрасту, а не только по времени.
• Separate access, application, and error logs if a service exposes more than one signal.Разделять access, application и error логи, если сервис отдает больше одного типа сигнала.
• Compress old files early and delete them on schedule.Рано сжимать старые файлы и удалять их по расписанию.
• Write down where logs live so restores and cleanups stay predictable.Фиксировать, где живут логи, чтобы восстановление и очистка оставались предсказуемыми.

If log growth surprises me twice, the problem is not retention policy alone. It usually means the service emits a signal that should be rate-limited or fixed upstream.Если рост логов удивляет меня дважды, проблема уже не только в retention policy. Обычно это значит, что сервис генерирует сигнал, который нужно либо ограничить, либо исправить выше по стеку.

/articles /notes