多Gunicorn worker下Django TimedRotatingFileHandler覆盖旧日志问题

问题根因 #

你遇到的覆盖问题本质是Python标准库的TimedRotatingFileHandler不支持多进程安全：

• Gunicorn多worker是独立的操作系统进程，所有worker进程会共享同一份Django日志配置，同时操作同一个debug.log文件
• 当到达日志轮转时间点时，多个worker会同时触发轮转逻辑：各自尝试把当前debug.log重命名为历史文件、再创建新的debug.log，这个过程没有进程锁，就会出现重命名冲突、旧日志被覆盖、日志丢失的问题
• 单worker场景下不存在多进程竞争，所以运行正常

可行解决方案 #

方案1：替换为进程安全的时间轮转日志处理器 #

使用第三方库concurrent-log-handler提供的并发安全版本处理器，内置文件锁解决多进程竞争问题：

1. 先安装依赖：

pip install concurrent-log-handler

2. 修改settings.py的日志配置：

'debug': {
    'level': 'DEBUG',
    'filename': BASE_DIR + '/Log/debug.log',
    'class': 'concurrent_log_handler.ConcurrentTimedRotatingFileHandler',
    'when': 'M',
    'interval': 1,
    'formatter': 'verbose',
    # 可选配置：设置最大备份数量
    'backupCount': 60
},

方案2：日志输出到标准流，由外部服务统一管理轮转 #

放弃在Django层面直接写本地文件，把所有日志输出到stdout/stderr，再通过以下任意方式管理：

• 由Gunicorn统一接管日志，配置Gunicorn的日志轮转参数，所有worker的输出都交给Gunicorn主进程处理写入
• 配合系统日志服务（rsyslog、journald）或者容器环境的日志采集能力做集中收集和轮转，完全规避本地多进程写文件的冲突

方案3：每个worker单独写独立日志文件 #

在日志文件名中加入当前进程PID，让每个worker写属于自己的日志文件，完全避免文件竞争：

import os
'debug': {
    'level': 'DEBUG',
    'filename': f"{BASE_DIR}/Log/debug_{os.getpid()}.log",
    'class': 'logging.handlers.TimedRotatingFileHandler',
    'when': 'M',
    'interval': 1,
    'formatter': 'verbose'
},

该方案的缺点是会生成多份日志文件，排查问题时需要合并查看。

方案4：接入集中式日志系统 #

把所有worker的日志直接上报到ELK、Loki等集中式日志服务，不需要本地写文件，从根源上避免多进程写文件的冲突问题，适合生产环境大规模部署使用。

内容的提问来源于stack exchange，提问作者Suresh