{"title":"logging结构化输出JSON设置方法"}

Python 的 logging 模块默认不支持结构化 JSON 日志输出，因其内置 Formatter 仅生成不可控的字符串，要实现可靠、可解析、可扩展的 JSON 日志，必须自定义 Formatter 子类——精准过滤不可序列化字段（如 exc_info、threading.Lock）、规范处理异常堆栈、统一时间格式，并通过 LoggerAdapter 或 Filter 安全注入 trace_id 等上下文字段；同时需规避多进程写入错乱、单文件多行 JSON 解析失败、序列化性能瓶颈等生产级陷阱，真正让日志既“机器友好”又“运维可靠”。

为什么默认的 logging 不能直接输出 JSON

Python 标准库的 logging 默认使用 Formatter，它把日志拼成字符串，字段顺序、类型、嵌套结构都不可控。想让日志变成 JSON，关键不是“加个参数”，而是替换掉格式化逻辑——必须自定义一个继承自 logging.Formatter 的类，重写 format() 方法，让它返回合法 JSON 字符串。

如何写一个可靠的 JSON Formatter

核心是：在 format() 中提取 record.__dict__，剔除不可序列化的字段（比如 exc_info、stack_info），再把异常和堆栈转成字符串后塞进新字典，最后用 json.dumps() 输出。常见错误是直接 dump 整个 record.__dict__，结果遇到 threading.Lock 或函数对象就报 TypeError: Object of type Lock is not JSON serializable。

• 必须过滤掉 exc_info、stack_info、msg（原始格式化字符串）、args（未格式化的元组）这些非基础类型字段
• 用 self.formatException(record) 和 self.formatStack(record) 获取可序列化的异常/堆栈字符串
• 推荐设置 ensure_ascii=False 和 separators=(',', ':') 减少体积
• 时间字段建议用 record.created 或 datetime.fromtimestamp(record.created)，别依赖 record.asctime（那是字符串，且格式不统一）

如何让 JSON 日志包含 trace_id 或 request_id

结构化日志的价值在于关联请求链路，但 logging.Record 默认不带上下文字段。不能靠全局变量或线程局部存储硬塞——并发下会错乱。正确做法是用 LoggerAdapter 或 Filter 动态注入字段。

• 用 LoggerAdapter 最简单：初始化时传入 extra={'trace_id': 'xxx'}，之后所有 logger.info() 调用都会自动带上该字段
• 如果需要动态值（比如从 Flask 请求中取 request.headers.get('X-Request-ID')），必须写自定义 Filter，在 filter(record) 里设置 record.trace_id = get_current_trace_id()
• 注意：Filter 注入的字段名必须在 JSON Formatter 的 format() 中显式读取，否则不会出现在输出里

FileHandler + JSON Formatter 的实际坑点

本地开发时用 FileHandler 配 JSON Formatter 没问题，但上生产常被忽略三点：

• 日志文件不能被多个进程同时写（比如 gunicorn 多 worker），否则 JSON 行会错乱——必须用 RotatingFileHandler + delay=True，或改用 QueueHandler + 单独写入进程
• 每行一个 JSON 是业界共识（方便 Logstash、Fluentd 解析），所以不要用 indent=2，也别把多条日志 dump 到一个大 JSON 数组里
• 如果日志量大，频繁调用 json.dumps() 有性能开销，可考虑用 ujson 替代标准库 json（需自行测兼容性）

JSON Formatter 不难写，难的是字段一致性、上下文注入时机、以及多进程下的输出可靠性——这三个地方出问题，日志就既不好查，也不好解析。

理论要掌握，实操不能落！以上关于《{"title":"logging结构化输出JSON设置方法"}》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！