必须选 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 <p>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' # 关键：去掉时分秒</p>
错误日志单独归档：为什么不能只靠 level 过滤？
仅用 logger.setLevel(logging.ERROR) 会导致 WARNING 及以上全进同一个文件，但运维真正要盯的是 ERROR 和 CRITICAL，WARNING 往往是可恢复的临时抖动。必须拆流：让 ERROR+CRITICAL 写入 error.log，其余写入 app.log。
陷阱在于：Python 日志器默认把子 logger 的日志向上冒泡到 root，结果 ERROR 日志在两个文件里各出现一次。解决方法是关掉 propagate：
立即学习“Python免费学习笔记（深入）”；
- 给 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 # 关键：阻断冒泡
<p>error_handler = TimedRotatingFileHandler(
'/var/log/myapp/error.log',
when='midnight',
backupCount=30,
utc=True
)
error_handler.setLevel(logging.ERROR)
error_logger.addHandler(error_handler)</p>归档后压缩与清理：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
}线上查错时找不到对应日志：时间戳对不上怎么办？
现象：告警显示 “2024-05-20 03:17:22 ERROR”，但翻遍 app.log.2024-05-20 和 app.log.2024-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 对两遍。
