Python错误日志归档策略_长期运维实践技巧【技巧】

必须选 TimedRotatingFileHandler,并设 when='midnight'、utc=True、delay=True、suffix='%Y-%m-%d'、backupCount=30;错误日志需单独 logger 并设 propagate=False;归档交由 logrotate 处理,启用 copytruncate 和 dateext;时区须统一为 UTC 或显式配置,确保时间戳对齐。

日志文件按天轮转但不丢数据:用 RotatingFileHandler 还是 TimedRotatingFileHandler

长期运行的 Python 服务,最常见问题是日志撑爆磁盘,或单个日志过大导致 grep 卡死、tail -f 失效。别直接上 RotatingFileHandler——它按大小切分,容易在凌晨流量高峰时突然切出几十个 .1.2 文件,且无法保证“每天一个文件”。必须选 TimedRotatingFileHandler,并严格设置 when='midnight'backupCount

关键细节:

  • utc=True 必须开启,否则跨夏令时可能漏切或重复切(尤其部署在海外服务器时)
  • delay=True 推迟文件打开,避免启动时因目录不存在报 FileNotFoundError
  • 文件名后缀用 %Y-%m-%d 而非默认的 %Y-%m-%d_%H-%M-%S,否则每天生成多个文件
  • backupCount=30 表示最多保留 30 天,超出的自动删除;设为 0 则不删,务必警惕
import logging
from logging.handlers import TimedRotatingFileHandler

handler = TimedRotatingFileHandler( filename='/var/log/myapp/app.log', when='midnight', interval=1, backupCount=30, encoding='utf-8', utc=True, delay=True ) handler.suffix = '%Y-%m-%d' # 关键:去掉时分秒

错误日志单独归档:为什么不能只靠 level 过滤?

仅用 logger.setLevel(logging.ERROR) 会导致 WARNING 及以上全进同一个文件,但运维真正要盯的是 ERROR 和 CRITICAL,WARNING 往往是可恢复的临时抖动。必须拆流:让 ERROR+CRITICAL 写入 error.log,其余写入 app.log

陷阱在于:Python 日志器默认把子 logger 的日志向上冒泡到 root,结果 ERROR 日志在两个文件里各出现一次。解决方法是关掉 propagate:

  • 给 error handler 绑定的 logger 设置 propagate=False
  • 确保两个 handler 的 level 不重叠(如 app handler 设 INFO,error handler 设 ERROR
  • 避免在同一个 logger 上加多个 handler 后又没控制好 level,引发重复写入
error_logger = logging.getLogger('error_only')
error_logger.setLevel(logging.ERROR)
error_logger.propagate = False  # 关键:阻断冒泡

error_handler = TimedRotatingFileHandler( '/var/log/myapp/error.log', when='midnight', backupCount=30, utc=True ) error_handler.setLevel(logging.ERROR) error_logger.addHandler(error_handler)

归档后压缩与清理:Linux logrotate 和 Python 自处理谁更稳?

Python 自己做压缩(比如用 zipfile 处理旧日志)风险高:进程可能被 kill 导致压缩中断,留下损坏的 zip;或压缩时占满 I/O,拖慢主业务。生产环境一律交给系统级 logrotate,Python 只管生成带日期的原始文件。

logrotate 配置要点:

  • dateext + dateformat %Y-%m-%d 匹配 Python 生成的文件名格式
  • compress 开启 gzip 压缩,比 Python 的 zipfile 更轻量、更可靠
  • maxage 90backupCount 更准——按文件修改时间算,不是按轮转次数
  • 务必加 copytruncate:logrotate 先拷贝再清空原文件,避免 Python 因文件被 mv 而写失败
/var/log/myapp/*.log {
    daily
    dateext
    dateformat -%Y-%m-%d
    compress
    maxage 90
    missingok
    copytruncate
    create 644 root root
}

线上查错时找不到对应日志:时间戳对不上怎么办?

现象:告警显示 “2025-05-20 03:17:22 ERROR”,但翻遍 app.log.2025-05-20app.log.2025-05-19 都没这条记录。大概率是 Python 进程时区和系统时区不一致。

根本原因:TimedRotatingFileHandler 默认用 time.localtime(),而系统日志(dmesgjournalctl)用 UTC 或本地时区。解决方案只有两个:

  • 所有机器统一设为 UTC 时区(推荐),然后 Python 里显式用 utc=True,日志时间戳就是纯 UTC,和系统日志对齐
  • 若必须用本地时区,则 Python 启动前执行 export TZ=Asia/Shanghai,且确认 timedatectl status 输出的时区和它一致
  • 绝对不要依赖 datetime.now().strftime() 手动拼日志行——绕过 logging 模块的时间控制,会彻底失去轮转能力

时区不对的日志,归档策略再完美也白搭。上线前第一件事:跑 python -c "import time; print(time.strftime('%Z %z'))"timedatectl 对两遍。