日志压缩包按日期乱成一锅粥，我写了个脚本按月份归档

后端干久了，日志压缩包比代码还多。我们服务每天往一个目录里扔 app-2024-05-13.log.gz 这种文件，三年攒了快两千个。每次要查历史问题，ls 出来一屏全是日期，按文件名排序是乱的，因为有的月份补零有的没补。

上周排查一个跨月问题，我翻目录翻了五分钟，忍不了了。

问题在哪

1. 文件名格式不统一：早期是 app-2024-5-3.log.gz，后来改成 app-2024-05-03.log.gz，排序直接错位。
2. 全部堆在一个目录：ext4 下单个目录文件数超过几千，ls 和 find 都会变慢，实测 ls 要等 2 秒多。
3. 没做校验：有几次解压出来发现文件头被同名文件覆盖过，日志内容缺了一段。

我的处理

写了个 Python 脚本，干三件事：

• 统一重命名成 YYYY-MM 格式，老文件用正则补零。
• 按月份建子目录，mv 进去（同分区是 rename，秒完成，不产生 IO）。
• 每月最后一天生成一个 manifest.sha256，解压前先 sha256sum -c 对一遍。

重点说第三条。之前踩过坑：两个服务往同一个目录写日志，压缩脚本并发跑，结果 app-2024-05-13.log.gz 被另一个进程覆盖了一半，gzip -t 能过，但解压出来是坏的。加了校验和之后，这种问题一眼就能揪出来。

实测数据

• 目录文件数从 1873 降到单目录最多 31 个，ls 从 2.1 秒降到 0.03 秒。
• 脚本跑全量重命名+归档，2000 个文件耗时 8 秒左右（纯 rename，没动数据）。
• 校验加进去之后，每月多花 3 秒算 sha256，换的是解压不踩雷，我觉得值。

注意点

• 别用 mv 跨分区，会变成 copy+delete，2000 个文件能跑几分钟。先确认 df 是不是同一个挂载点。
• 重命名前先 find 列一遍待改列表，输出到文件，确认没误伤再批量跑。我第一版正则写错，把 app-2024-05-13 改成了 app-2024-05-13-13，还好先 dry-run 了。
• 如果是 Windows 上处理这些包，Win解压缩解压速度确实快，但批量重命名和校验对我还是命令行顺手，这块 7-Zip 的 -so 输出到 stdout 配合 sha256sum 更灵活。

遗留问题

现在脚本是手动跑的，我想挂到 cron 里每天凌晨自动归档，但担心和日志轮转的 logrotate 抢文件，时序上还没想清楚怎么排。

你们日志归档是手动还是自动？有没有和 logrotate 打配合的经验？