必须采用size触发策略替代daily/weekly等时间策略，设阈值50M–200M、rotate 7、启用copytruncate和compress，禁用create/sharedscripts及delaycompress，并验证生效。
Debug模式开启后，应用日志量常呈数倍增长，单小时就可能写入数百MB甚至上GB日志，IO压力陡增、磁盘快速耗尽。此时依赖daily或weekly这类时间型轮转完全失效——日志还没等到第二天就已撑爆磁盘。必须改用size触发策略，主动控大小、减IO冲击、保服务稳定。
用 size 替代时间周期，实现按需轮转
时间策略在Debug场景下形同虚设；size才是精准响应高写入的关键。它一检测到文件达到阈值（如100M），立即执行轮转，避免单文件持续追加带来的fsync堆积和IO阻塞。
-
必须移除 daily/weekly/monthly：这些与
size共存时，logrotate 会优先按时间判断，导致大小限制被忽略 - 推荐阈值设为 50M–200M：太小（如10M）会导致轮转过于频繁，增加inode和压缩开销；太大（如1G）则起不到缓解IO的作用
-
搭配 rotate 控制保留数量：例如
rotate 7表示最多保留7个归档，防止历史日志无限累积
必须启用 copytruncate，避免服务中断
Debug日志往往由不支持重开日志的进程直写（如某些Java应用、自研二进制程序），若用默认的mv+create方式，进程因文件句柄指向已重命名的旧文件而继续写入，新日志文件却无人写入——造成日志丢失。
-
copytruncate是唯一安全选项：先复制当前内容，再清空原文件，进程无需重启或重载即可继续写入同一路径 - 注意微小风险：复制与清空之间存在毫秒级窗口，极端高并发下可能丢失极少量日志，但远优于服务中断或日志断流
-
禁用 create 和 sharedscripts：二者与
copytruncate逻辑冲突，配置中应显式去掉
配合压缩与清理，降低IO与存储压力
Debug日志虽需保留排查，但原始文本体积大、读取慢、IO重。压缩不是可选项，而是IO优化的必要环节。
- 必加 compress：gzip压缩通常可将文本日志缩小70%–90%，显著减少磁盘写入量和空间占用
- 慎用 delaycompress：它让最新一轮归档暂不压缩，虽略减CPU，但延长了大文件存在时间，加剧IO压力；Debug场景建议直接压缩
- 搭配 notifempty + missingok：避免空日志或临时缺失路径触发错误，保障定时任务稳定执行
验证配置生效并监控实际效果
配完不等于跑通。Debug模式下日志暴增，必须确认logrotate真正在工作，而非“静默失效”。
-
手动测试轮转：运行
sudo logrotate -vf /etc/logrotate.d/myapp，观察是否生成.1.gz文件、原文件是否被截断至0字节 -
检查状态文件：查看
/var/lib/logrotate/status中对应日志路径的最后轮转时间，确认是否随size增长实时更新 -
监控磁盘IO变化：用
iostat -x 1对比开启前后%util和await指标，理想情况是单次写入变小、频率升高，但总体IO负载下降
