📚 课程目录第4章日志文件存储与轮转策略

日志文件存储与轮转策略

日志文件不是无限长的。你想想看，一个高并发的加密SDK，每秒可能输出几百条调试日志，如果不做轮转，一个文件能撑到几个GB？不仅打开看都费劲，还会把磁盘撑爆。我早期一个项目就吃过这个亏——生产环境日志直接写到了50GB，导致系统磁盘告警，业务被迫中断。从那以后，日志轮转变成了我每次架构设计时必须画进图里的模块。

为什么需要轮转？三个核心原因

磁盘空间有限：再大的磁盘也扛不住无限增长，尤其是云上临时盘或容器化部署。
查询效率：一个几GB的日志文件，你用vi打开都卡，grep搜个关键词能等十几秒。
维护与回溯：按天或按小时切分后，排查问题可以快速定位到特定时间片，不用在一个大文件里大海捞针。

主流的轮转策略

我个人习惯把轮转策略分为三类：按大小、按时间、混合模式。下面这个对比表可以帮你快速选择。

策略	触发条件	适用场景	我的踩坑经验
按大小（Size-based）	文件达到指定字节数	单次请求量波动大，不关心时间片	要配合最大文件数，否则旧文件会被覆盖
按时间（Time-based）	到达固定间隔（天/时/分）	运维习惯按日期归档、审计合规场景	如果某时段流量极低，会产生很多小文件
混合模式	时间和大小双重条件	生产环境最推荐，平衡存储和可读性	配置时要定好优先级，否则可能频繁轮转

我的习惯：用Python的TimedRotatingFileHandler做时间轮转，再额外加个maxBytes限制。即使某几秒流量突增，也不会让单个日志文件超过合理大小。

日志文件命名与目录结构

一个好的命名规范，能省掉你一半的排查时间。我曾经接手过一个项目，日志文件名是log_001.log、log_002.log… 没有时间戳，也没有模块标识。出问题后根本不知道哪个文件对应哪天的数据。后来我强制团队使用统一格式：

日志目录结构建议：
/app/logs/
  ├── sdk_crypto/
  │   ├── crypto-2025-03-20.log
  │   ├── crypto-2025-03-20.1.log.gz
  │   └── crypto-2025-03-21.log
  └── sdk_network/
      ├── network-2025-03-20.log
      └── network-2025-03-20.1.log.gz

文件名包含模块名 + 日期 + 序号 + 可选的压缩后缀。这样用ls -ltr一看就知道顺序。另外，日志目录最好挂载在独立分区或使用tmpfs（临时文件系统），避免日志写入影响主业务IO。

轮转流程图：一次完整过程

下面这张图是我在实际培训时常用的，它把一次日志轮转的完整链路画了出来。记住这个流程，配置时就不会漏掉任何环节。

配置示例：Python logging 实现

这里给一个我自己在加密SDK中常用的配置模板。用了TimedRotatingFileHandler按天轮转，并控制最多保留7个备份文件。注意 backupCount 参数——我曾经忘记写它，结果日志文件越积越多，把磁盘打满了。

import logging
from logging.handlers import TimedRotatingFileHandler

handler = TimedRotatingFileHandler(
    filename='/app/logs/sdk_crypto/crypto.log',
    when='midnight',         # 每天0点轮转
    interval=1,
    backupCount=7,           # 保留最近7天的日志
    encoding='utf-8',
    utc=True                 # 用UTC时间避免时区混乱
)

formatter = logging.Formatter(
    '%(asctime)s [%(levelname)s] %(module)s: %(message)s'
)
handler.setFormatter(formatter)

logger = logging.getLogger('crypto_sdk')
logger.addHandler(handler)
logger.setLevel(logging.DEBUG)

特别注意：如果日志写入量特别大，单日文件可能仍然会超过1GB。我建议在TimedRotatingFileHandler基础上，额外加一层RotatingFileHandler做大小限制，或者使用WatchedFileHandler配合 logrotate 系统工具。容器环境中还要考虑 stdout 重定向，避免宿主机与容器内日志轮转冲突。

轮转后的清理与压缩

轮转只是第一步，清理才是省钱省空间的关键。我的做法是：

旧日志压缩：轮转后立即用gzip压缩旧文件，通常能缩小到原始大小的10%~20%。
保留策略：调试日志保留7天，错误日志保留30天，关键审计日志保留90天以上。
冷备迁移：超过保留周期的日志可以异步上传到对象存储（如S3），本地只保留最近30天。

实际坑点：我曾经因为压缩太晚（每天凌晨压缩），导致凌晨1点轮转时旧文件还没压缩完，新日志又写入到重命名后的文件里，造成日志丢失。后来我把压缩放在轮转触发后立即异步执行，用subprocess后台gzip，不影响主线程。

安全性注意事项

日志文件包含敏感信息（密钥、、交易摘要），权限控制不能马虎：

安全维度	建议操作
文件权限	日志目录设置为 `750`，文件 `640`，仅日志进程和运维组可读
日志内容过滤	在输出前过滤掉敏感字段（如使用 `re.sub` 替换密钥）
轮转脚本安全	避免使用 `rm -f` 硬删除，改用 `move` 到回收目录或使用 `logrotate` 的 `delaycompress` 选项

嗯，日志轮转虽然基础，但配置不当引发的故障往往很隐蔽。我希望你读完这一章，能立刻去检查一下你的加密SDK日志是否有合理的轮转策略——别像我当初那样，等到磁盘报警才想起来。多看日志、多埋监控，才是排查问题的最稳解法。