日志轮转方案：按大小和时间设置

Python 的日志轮转机制中，RotatingFileHandler 仅支持按文件大小轮转，而 TimedRotatingFileHandler 仅支持按时间轮转，二者均无法原生实现“大小或时间任一条件满足即触发轮转”的双重策略；文章深入剖析了通过继承 TimedRotatingFileHandler 并重写 shouldRollover() 方法来融合两种轮转逻辑的技术方案，同时警示了多进程竞争、backupCount 语义歧义、额外编号文件残留等易被忽视的生产隐患，并针对不同场景（单进程轻量、多进程高可靠、容器化部署）给出了务实选型建议——从自定义处理器到 concurrent-log-handler，再到交由外部工具（如 logrotate 或 fluentd）统一管理，帮你避开日志失控、磁盘爆满和排查断档的陷阱。

RotatingFileHandler 本身不支持大小+时间双重轮转

logging.handlers.RotatingFileHandler 只能按文件大小（maxBytes）或按数量（backupCount）轮转，它**完全不感知时间**，也没有 when、interval 这类参数。想实现“达到 10MB 或过了一天就切日志”，不能只靠它。

用 TimedRotatingFileHandler + 自定义判断逻辑补足大小限制

logging.handlers.TimedRotatingFileHandler 支持按时间轮转（如每天切一次），但它默认不检查文件大小。要加大小控制，得在每次写入前手动判断当前日志文件是否超限，并触发强制 rollover：

• 重写 shouldRollover() 方法：除了原逻辑（时间到了？），再加一条 —— 当前文件大小 ≥ maxBytes 就返回 True
• 重写 doRollover() 方法（可选）：确保 rollover 后清空原文件或重命名逻辑与时间轮转兼容
• 注意：不要直接修改 self.stream 的位置或 close 它，否则会破坏父类的 time-based rollover 流程

示例关键片段：

class SizeAndTimeRotatingHandler(TimedRotatingFileHandler):
    def __init__(self, filename, when='midnight', interval=1, backupCount=7,
                 encoding=None, delay=False, utc=False, atTime=None, maxBytes=0):
        super().__init__(filename, when, interval, backupCount, encoding,
                         delay, utc, atTime)
        self.maxBytes = maxBytes
<pre class="brush:php;toolbar:false"><code>def shouldRollover(self, record):
    # 先让父类判断是否该按时间 rollover
    tflag = super().shouldRollover(record)
    if tflag:
        return True
    # 再检查大小
    if self.maxBytes > 0 and self.stream is not None:
        self.stream.seek(0, 2)  # 移动到文件末尾
        if self.stream.tell() >= self.maxBytes:
            return True
    return False</code>

更稳妥的做法：用 concurrent-log-handler 或 logrotate 配合

自己维护双条件 rollover 容易出竞态或遗漏边界（比如多进程写同一个文件、rollover 中断、时区切换）。生产环境建议：

• 单进程且逻辑简单 → 用上面自定义 handler，但务必测试 maxBytes=0（禁用大小）和 when='S'（秒级）等边界场景
• 多进程/高可靠要求 → 改用 concurrent-log-handler 包（它内部用文件锁），再配合外部 logrotate 做二次清理（例如：保留 7 天 + 每个文件不超过 100MB）
• 容器环境 → 直接 stdout 输出，由 docker daemon 或 fluentd 按大小+时间切分，Python 层不做轮转

容易被忽略的细节：backupCount 对两种轮转方式的意义不同

backupCount 在 TimedRotatingFileHandler 中控制的是「保留多少个历史时间段的日志」（如 backupCount=7 表示留最近 7 天的 .2024-05-01、.2024-05-02…），不是「最多 7 个备份文件」。如果某天内因超大小又切了多个文件（如 app.log.2024-05-01.1、.2），这些额外文件不会被自动清理 —— 除非你额外实现 doRollover() 里遍历删除旧编号。

也就是说，大小+时间叠加后，backupCount 不再是总文件数上限，实际磁盘占用可能远超预期。

终于介绍完啦！小伙伴们，这篇关于《日志轮转方案：按大小和时间设置》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！