Python 结构化日志的实践经验

1次阅读

loguru 更适合快速落地因其默认支持结构化输出、自动轮转和线程安全,无需手动配置 handler/formatter/level;structlog 依赖绑定机制与上下文管理器维持请求上下文;json 中文转义需设置 ensure_ascii=false;字段命名应统一 snake_case 以利日志查询。

Python 结构化日志的实践经验

loguru 为什么比 Logging.basicConfig 更适合快速落地

因为 loguru 默认就支持结构化输出(JSON)、自动轮转、线程安全,且不用写 handler + formatter + level 三件套。原生 logging 要输出 JSON,得自己重写 JSONFormatter,还容易在多进程下丢日志。

实操建议:

立即学习Python免费学习笔记(深入)”;

  • 直接 pip install loguru,导入即用:from loguru import logger
  • logger.add("file.json", serialize=True) 就能输出结构化 JSON,字段含时间、级别、模块、行号、消息、异常
  • 别在 logger.add() 里传 format 字符串——serialize=True 会忽略它;要加额外字段,用 logger.bind(user_id=123)
  • 注意 serialize=True 后,日志内容里的对象必须可 JSON 序列化,否则会静默失败(比如写了 logger.info({"data": datetime.now()}) 就会卡住)

structlog 在 djangofastapi 中怎么不破坏请求上下文

因为 structlog 本身不处理输出,只负责“组装结构”,但它的绑定机制(bind()/new())和上下文管理器配合得好,就能把 trace_id、user_id 这类请求级字段自动带上每条日志。

实操建议:

立即学习Python免费学习笔记(深入)”;

  • 中间件里用 structlog.contextvars.bind_contextvars(request_id=request.state.request_id) 注入请求 ID
  • 避免在全局 logger 上反复 bind(),应该每次请求开始时 logger = logger.bind(request_id=...),然后把这个新 logger 传进视图或依赖注入
  • structlog.stdlib.filter_by_levelstructlog.stdlib.ProcessorFormatter 才能兼容 Django 的 LOGGING 配置,否则日志全变成 str 丢进 stdout
  • 别忘了调 structlog.configure() 设置 processors,漏掉 structlog.processors.JSONRenderer 就还是纯文本

JSON 日志里出现 u4f60u597d 怎么办

这是 python 默认 JSON encoder 把中文转义了,不是编码错误,是 ensure_ascii=True 的锅。

实操建议:

立即学习Python免费学习笔记(深入)”;

  • loguru 用户:加参数 logger.add("app.json", serialize=True, rotation="10 MB", enqueue=True, catch=True, format="{message}") 不够,还得改 encoder —— 传 serializer 函数,里面用 json.dumps(..., ensure_ascii=False)
  • structlog 用户:在 JSONRenderer 后加 structlog.processors.UnicodeDecoder() 没用,得在 structlog.configure(processors=[..., JSONRenderer(indent=2, ensure_ascii=False)])
  • 原生 logging + 自定义 JSONFormatter:重写 self._encoder = json.JSONEncoder(ensure_ascii=False),别只改 json.dumps 调用点——logging 内部会自己调用 encoder

日志字段命名要不要统一用 snake_case

要,但不是为了风格洁癖,而是为后续 elk 或 Loki 查询省事。比如 user_iduserId 在 Kibana 里会被当成两个字段,聚合统计就断了。

实操建议:

立即学习Python免费学习笔记(深入)”;

  • 所有自定义字段名统一用 snake_case,包括 trace_id、status_code、request_method
  • 第三方库返回的字段(如 OpenTelemetry 的 trace_id)保持原样,别强行 camelCase 转换——工具链认的是标准字段名
  • 如果用 Loki,level 必须小写("info"),大写("INFO")会导致 level="info" 查询不到
  • 字段值尽量别嵌套太深,{"request": {"user": {"id": 123}}} 查起来比 {"user_id": 123} 多写一倍 PromQL

结构化日志最难的不是输出 JSON,是让每条日志都带对上下文——中间件没接好、异步任务没传递 logger 实例、异常捕获后没重新 bind,都会导致关键字段丢失。这些地方不写测试,线上基本靠猜。

text=ZqhQzanResources