Loguru日志库中日期轮转的正确配置方法
2025-05-10 15:03:52作者:齐添朝
在使用Python的Loguru日志库时,合理配置日志文件的日期轮转是一个常见需求。本文将通过一个实际案例,详细介绍如何正确设置基于日期的日志轮转功能。
问题背景
在Django REST服务中,开发者希望通过Loguru实现每日自动创建新日志文件的功能。初始配置使用了Python的f-string来动态生成包含当前日期的日志文件名:
logFile = os.path.join(logDir, f"service_{datetime.date.today()}.log")
然而这种配置方式会导致两个问题:
- 轮转时不会创建预期的新日期文件,而是在原文件名后追加时间戳
- 新日志内容继续写入旧日期的日志文件中
问题分析
根本原因在于f-string在程序启动时就被求值并固定下来。当Loguru执行轮转操作时,它认为这是一个静态文件名,因此采用追加时间戳的方式处理轮转文件,而不是按照开发者期望的每日创建新文件。
正确解决方案
Loguru提供了内置的时间占位符功能,可以动态处理日期变化。正确的配置方式应该是:
logFile = os.path.join(logDir, "service_{time:YYYY-MM-DD}.log")
logger.add(logFile, rotation="00:00")
这种配置的优势在于:
{time:YYYY-MM-DD}是Loguru的占位符语法,会在文件创建/重新创建时自动替换为当前日期- 配合
rotation="00:00"参数,系统会在每天午夜自动轮转日志 - 无需手动处理文件重命名逻辑,由Loguru内部自动管理
实现原理
Loguru的时间占位符功能基于以下工作机制:
- 在初始化时,Loguru会解析文件名中的
{time}格式字符串 - 每次写入日志时,会检查当前时间是否符合轮转条件
- 当需要轮转时,会根据当前时间重新计算文件名中的日期部分
- 自动处理旧日志文件的归档和新日志文件的创建
最佳实践建议
- 避免在外部计算文件名:不要使用Python的f-string或datetime计算文件名,应使用Loguru内置的占位符
- 简化压缩逻辑:除非有特殊需求,否则不需要自定义压缩/重命名函数
- 考虑时区因素:如果应用跨时区部署,确保服务器时间设置正确
- 测试轮转行为:通过修改系统时间或使用特定工具验证轮转是否按预期工作
通过正确使用Loguru的时间占位符功能,开发者可以轻松实现基于日期的日志轮转,确保日志文件按天分割,便于后续的日志管理和分析。
登录后查看全文
热门项目推荐
相关项目推荐
atomcodeClaude Code 的开源替代方案。连接任意大模型,编辑代码,运行命令,自动验证 — 全自动执行。用 Rust 构建,极致性能。 | An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get StartedRust0214
cann-learning-hubCANN 学习中心仓,支持在线互动运行、边学边练,提供教程、示例与优化方案,一站式助力昇腾开发者快速上手。Jupyter Notebook0138
uni-appA cross-platform framework using Vue.jsJavaScript08
GLM-5.2智谱开源 GLM-5.2,这是针对长文本任务的最新旗舰模型。相较于前代产品 GLM-5.1,它在长文本任务处理能力上实现了显著飞跃,并且首次在稳定的 100 万 token 上下文中提供这一能力。Jinja00
SwanLab⚡️SwanLab - an open-source, modern-design AI training tracking and visualization tool. Supports Cloud / Self-hosted use. Integrated with PyTorch / Transformers / LLaMA Factory / veRL/ Swift / Ultralytics / MMEngine / Keras etc.Python00
tiny-universe《大模型白盒子构建指南》:一个全手搓的Tiny-UniverseJupyter Notebook03
项目优选
收起
deepin linux kernel
C
32
16
openEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。
C
469
465
暂无描述
Dockerfile
778
5.08 K
本项目是CANN提供的transformer类大模型算子库,实现网络在NPU上加速计算。
C++
877
2.03 K
Ascend Extension for PyTorch
Python
758
968
本项目是CANN提供的神经网络类计算算子库,实现网络在NPU上加速计算。
C++
697
1.4 K
昇腾LLM分布式训练框架
Python
185
231
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
1.1 K
1.14 K
本仓库是 Flutter SDK 与 Flutter Engine 的 OpenHarmony 适配版本,由 CPF-Flutter 团队维护。开发者可使用熟悉的 Flutter 技术栈开发 OpenHarmony 应用,3.35.7 及以后的适配版本可基于本仓库源码构建支持 OpenHarmony 的 Flutter Engine。
Dart
1.04 K
271
JiuwenSwarm 是一款基于openJiuwen开发的智能AI Agent,它能够将大语言模型的强大能力,通过你日常使用的各类通讯应用,直接延伸至你的指尖。
Python
2.25 K
677