闭源业务日志需采用“软切分+原子归档”策略：按时间戳切分、mv原子重命名、touch还原权限，配合进程存活检查、磁盘空间监控与systemd定时执行。
理解业务日志特性是前提
闭源业务通常不提供日志轮转接口，日志文件持续追加、不自动切分，可能单个文件达GB级，甚至进程独占写入（如flock或fd未释放）。直接用logrotate硬切会触发写入失败或丢日志。必须绕过“信号通知”和“重命名竞争”，采用“软切分+原子归档”策略。
核心思路：时间戳切分 + 进程无感归档
不依赖业务进程配合，改由外部脚本按时间（如每天00:00）触发切分，关键点在于：
- 切分瞬间不中断写入
- 新日志写入新文件，旧日志立即可压缩归档
- 保留最近N天原始日志+M个压缩包，防磁盘打满
- 用
date -d "yesterday" +%Y%m%d生成昨日日期标签，避免时区/系统时间误差 - 用
mv原子重命名原日志为app.log.20240520，Linux下只要同文件系统，mv是原子操作，业务进程继续写新创建的app.log - 新日志文件用
touch app.log && chown $APP_USER:$APP_GROUP app.log还原属主权限，避免业务因权限拒绝写入
防冲突与容错设计
闭源程序常静默运行，无法查状态。脚本需自带守护逻辑：
- 每次执行前用
lsof -t -w -n -c "$APP_PROC_NAME" | head -1确认主进程存活，否则跳过切分 - 检查目标日志路径是否可写、磁盘剩余空间是否＞5GB（
df /var/log | awk 'NR==2 {print $4}'），不足则发告警并退出 - 归档前对旧日志
gzip -c app.log.YYYYMMDD > app.log.YYYYMMDD.gz && rm app.log.YYYYMMDD，避免大文件阻塞IO - 用
find /var/log/app -name "app.log.*.gz" -mtime +30 -delete清理超期压缩包，不依赖logrotate的rotate计数
部署与验证要点
脚本须脱离用户会话长期运行，推荐systemd定时器而非crontab：
- 写
/etc/systemd/system/app-log-rotate.timer，设置OnCalendar=00:00:00，精度高且支持随机延迟 - 配套
.service中Type=oneshot+RemainAfterExit=yes，便于手动调试systemctl start app-log-rotate.service - 首次上线前，在测试环境模拟：手动创建1GB日志文件→启动业务→运行脚本→检查
ls -lt /var/log/app是否出现带日期后缀的新归档、原文件是否清空、业务进程是否仍在写新app.log
不复杂但容易忽略：所有路径写绝对路径，所有命令加完整路径（如/usr/bin/find），避免systemd环境变量缺失导致失败。
