app.log 没配轮转 三个月涨到 40GB 写满分区

脚本自己写 app.log，只追加不切割，三个月 40GB，分区使用率到 100%，数据库写入开始报 No space left on device。乍看像缓存或者权限的锅，追下去往往不是。

/var/log/app.log {
  daily
  rotate 7
  compress
  copytruncate
}

追下去是这么回事：输出重定向到固定文件名，没有任何切割策略。日志增长速度按每天几百 MB 算，没人清理就一直涨到分区上限。

碰到「日志未轮转」这类问题，我习惯先把当前配置原样备份一份，改坏了立刻换回来，不用现场推。接口问题先分清是没发出去、发出去了没收到，还是收到了处理失败。

偶发问题先统计频率，一小时几次和一天一次，查法完全不同。改完顺手把文档补一句，省得下次自己重新推一遍。

监控和日志的时间要对上，时区不一致会多绕很大一圈。临时改动用注释写上日期和原因，过两周自己都记不清为什么这么写。

具体做法是，接 logrotate 按天切割保留 7 天；切割后让脚本重新打开文件 或者用 copytruncate；加 compress 压缩历史文件；观察一周 确认目录总大小稳定在 2GB 以内。

验收就看一点，logrotate 跑一次后出现 app.log.1.gz，目录总大小不再随天数增长。