17370845950

必须选 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 90 比 backupCount 更准——按文件修改时间算，不是按轮转次数
• 务必加 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-20 和 app.log.2025-05-19 都没这条记录。大概率是 Python 进程时区和系统时区不一致。

根本原因：TimedRotatingFileHandler 默认用 time.localtime()，而系统日志（dmesg、journalctl）用 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 对两遍。