Django生产日志记录与Logging配置指南

在Django生产环境中，日志配置绝非简单复制默认设置——DEBUG=False时若未手动配置RotatingFileHandler并按级别分离INFO与ERROR日志，极易因邮件发送失败、console被禁用或配置键名拼写错误（如handers、formater）导致关键错误日志静默丢失；本文直击痛点，详解如何通过精准的handlers与loggers显式定义、权限可控的绝对路径、level层级配合及上线前实测验证，构建稳定、可追溯、不丢日志的生产级日志体系，让每一行ERROR真正落盘可查。

生产环境日志必须按级别分离、滚动归档、避免丢日志——Django 默认的 LOGGING 配置不满足，得手动配 RotatingFileHandler 或 TimedRotatingFileHandler，并关掉 DEBUG=True 下的干扰行为。

为什么 Django 开发配置在生产里会丢 ERROR 日志？

Django 默认把 DEBUG=False 时的 ERROR 日志发给 AdminEmailHandler，但没配邮箱或邮件后端失败，日志就静默消失了；同时，console handler 在生产里通常被禁用，导致没有任何落盘记录。

• 确认 DEBUG=False 后，LOGGING 字典里是否显式定义了 handlers 和 loggers，而不是只依赖默认值
• 检查 LOGGING['loggers']['django']['handlers'] 是否包含文件 handler，而非只有 ['console', 'mail_admins']
• 确保 LOGGING['handlers'] 中的文件 handler 指向有写权限的路径（如 /var/log/myapp/），且目录已创建

怎么用 RotatingFileHandler 实现 ERROR/INFO 分开归档？

按级别拆日志最实用：INFO 级别进 app.log，ERROR 进 error.log，每份最大 10MB、保留 5 个旧文件。关键在 handler 的 level 和 logger 的 level 要配合，否则会漏。

• 定义两个 handler：'info_file'（level='INFO'，maxBytes=10485760）和 'error_file'（level='ERROR'，同样参数）
• 对应两个 logger：'django' 和 'myapp' 都要设 level='INFO'，并把两个 handler 都加进 handlers 列表
• 靠 handler 自身的 level 过滤：即使 logger 发 INFO，error_file handler 也会忽略它
• 注意 backupCount=5 是保留 5 个压缩/轮转文件，不是总共存 5 个

'handlers': {
    'info_file': {
        'level': 'INFO',
        'class': 'logging.handlers.RotatingFileHandler',
        'filename': '/var/log/myapp/app.log',
        'maxBytes': 10485760,
        'backupCount': 5,
        'formatter': 'verbose',
    },
    'error_file': {
        'level': 'ERROR',
        'class': 'logging.handlers.RotatingFileHandler',
        'filename': '/var/log/myapp/error.log',
        'maxBytes': 10485760,
        'backupCount': 5,
        'formatter': 'verbose',
    },
}

Django 的 LOGGING 配置里哪些 key 容易写错？

拼错 key 名是静默失效的主因，比如 handers（少个 l）、formater（少个 t）、propagate 写成 propogate，Django 不报错，但对应功能完全不生效。

• LOGGING['handlers'] 下每个 handler 必须有 'class'，且值是字符串完整路径：'logging.handlers.RotatingFileHandler'，不能漏 logging.
• LOGGING['loggers'] 下的 logger 必须有 'handlers'（复数）和 'level'，漏掉 'handlers' 就等于没接任何输出目标
• 'propagate': False 要加在自定义 logger 上，否则日志会向上透传到 root logger，可能重复写入
• 所有路径（filename、LOGGING 字典所在文件位置）用绝对路径，避免因 manage.py 执行路径不同导致写入失败

为什么 TimedRotatingFileHandler 在某些服务器上轮转失败？

TimedRotatingFileHandler 按时间轮转（比如每天一个文件），但依赖进程持续运行 —— 如果用 systemd 或 supervisor 管理 Django（如 runserver 不适用），且服务重启频繁，就可能错过轮转时机，或生成带错误时间戳的文件名（如 app.log.2024-01-01 但内容是 1 月 2 日的）。

• 生产推荐优先用 RotatingFileHandler：简单、稳定、不依赖启动时间
• 如果坚持用 TimedRotatingFileHandler，确保 when='midnight' 且 utc=False，并配合 cron 每天零点前发 SIGHUP 重载日志（需自定义 signal handler）
• 注意 delay=True 参数：避免 Django 启动时立即创建空日志文件，等第一次 log 调用再建
• 轮转后的旧文件权限继承自原文件，若用不同用户跑进程（如 nginx + gunicorn），可能因权限问题无法删除旧文件

真正难的不是写对那几行 LOGGING 配置，而是确认每条 ERROR 是否真的落到了磁盘、有没有被其他 handler 截胡、轮转后旧日志能不能查到 —— 建议上线前用 logger.error("test prod log") 手动触发，立刻去对应路径 tail -f 看效果。

理论要掌握，实操不能落！以上关于《Django生产日志记录与Logging配置指南》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！