Spring Boot 3.5 结构化日志实战：别让 JSON 日志变成新的噪音

Spring Boot 3.5 继续把结构化日志往生产可用方向推进，ECS、GELF、Logstash 这些格式终于不用每个项目手搓一套 logback 配置。但我见过不少团队切成 JSON 后，排障并没有更快，只是把文本噪音换成了 JSON 噪音。

本文适用于 Java 17/21、Spring Boot 3.4/3.5、Logback/Log4j2、Actuator/Micrometer 体系。Spring 官方文档和 release notes 只用于核对 structured logging、ECS/GELF/Logstash 支持和观测能力，正文按生产改造复盘写。

业务场景：出了错，却只能搜到一堆漂亮 JSON

一次支付回调超时，日志平台里有 traceId、spanId、orderId，看起来字段很多。真正排查时才发现，不同服务字段名一会儿叫 orderId，一会儿叫 order_id，还有的放在 message 里。JSON 是结构化了，团队约定没有结构化。

更麻烦的是异常堆栈全量进索引，日志量涨了三倍，告警规则还在匹配旧文本。上线第一天大家都觉得高级，第二天开始嫌日志平台慢。

先定字段契约，再谈格式

我会先定一张字段表：时间、级别、logger、traceId、spanId、service、environment、bizId、errorCode、exceptionType、message。字段少一点没关系，关键是跨服务一致、类型稳定、能被索引。

Spring Boot 的结构化日志格式解决的是输出形态，业务字段治理还得自己做。比如订单系统就明确只放 orderId，不放完整用户资料；支付系统只放支付单号，不把回调原文整段塞进日志。

问题复现：MDC 没清理，日志串味

结构化日志常见事故不是配置错，而是上下文生命周期错。MDC 放进去以后没有清理，异步线程里上下文断掉，或者线程复用时把上一个请求的 orderId 打到下一条日志里。

上线检查清单

• 确认分类和主题都是 Java/Spring Boot，不把日志平台部署问题写成主线。
• 字段名是否跨服务一致，是否有索引模板和类型约束。
• MDC 是否在 finally 或 try-with-resources 中清理。
• 异常日志是否脱敏，是否避免打印完整请求体和 token。
• 日志体积、索引成本、采样策略是否经过压测。
• 告警规则是否从文本匹配迁移到字段查询。

我的经验

结构化日志不是为了让日志看起来像一份 JSON 简历，而是让故障检索稳定、链路串联清楚、告警规则少一点玄学。先治理字段，再切格式；先灰度成本，再全量推广。