公司排查一个异步任务异常，在 ELK 里搜对应的 requestId，搜出来的日志只有主线程的。异步线程里的日志一条都没搜到——因为 MDC 里的 requestId 根本没有传到异步线程里。异步线程打出来的日志，requestId 是空的。一整条调用链在异步这个节点断掉了。 问题很直接：@Async 用一个线程池执行任务，但 MDC 是基于 ThreadLocal 的，ThreadLocal 不会自动从主线程传到子线程。异步线程里 MDC.get("requestId") 返回 null，日志里就少了这条 key。 今天聊聊怎么用 TransmittableThreadLocal（TTL）把主线程的上下文透传到异步线程里。 为什么 ThreadLocal 不行，TTL 就行 ThreadLocal 的一个基本特性：子线程拿不到父线程的值。 主线程里 MDC.put("requestId", "abc123")，然后 @Async 开一个新线程去执行，新线程里 MDC.get("requestId") 是 null。 一个直觉的解法是调用线程池时手动传参数。把 requestId ....

一、深夜救火现场：你的日志在“裸奔”吗？ 凌晨2点，线上报警！用户反馈“支付成功但订单未生成”。 你冲到ELK控制台，输入“支付成功”，哗啦啦刷出10万条日志... “哪条是这位用户的请求？”“中间哪步丢了数据？” 翻了40分钟，眼睛发酸，冷汗直流😅 你是否也经历过： 🔍 多个用户请求日志混杂，靠时间戳“猜”关联 🌪️ 异步任务/线程池日志突然“失联” 🤯 微服务调用链断裂，像断了线的珠子 今天，教你用MDC+traceId给日志装上“身份证” 一次请求所有日志自动带唯一标识，排查效率直接翻倍！✨ 二、MDC是啥？为什么它能救命？ MDC（Mapped Diagnostic Context）：Logback/Log4j提供的“线程级上下文容器” 👉 简单说：在一个请求线程里存个traceId，后续所有日志自动带上它！ 💡 灵魂价值： 一次请求生成唯一traceId，贯穿Controller→Service→DAO→异步任务 日志检索时，直接搜traceId，秒级定位全链路 为后续接入SkyWalking等APM打下基础（低成本起步！） 🌰 类比：就像快递单号！....

日志排查的痛点 在我们的日常开发和运维工作中，经常遇到这样的场景： 线上出问题了，需要快速定位是哪个用户的请求出了问题 查看日志时发现一堆请求混在一起，分不清哪个是哪个 需要追踪一个请求从进入系统到结束的完整链路 分布式系统中，一个请求经过多个服务，日志分散在各处 传统的日志记录方式往往只能看到零散的信息，无法形成完整的请求链路视图。 解决方案思路 今天我们要解决的，就是如何用阿里TTL + Log4j2 + MDC实现轻量级的日志链路追踪。 核心思路是： 请求链路追踪：为每个请求生成唯一标识 上下文传递：在请求处理过程中保持追踪标识 日志关联：将追踪标识添加到每条日志中 跨线程传递：确保异步处理时追踪信息不丢失 技术选型 阿里TTL（TransmittableThreadLocal）：解决线程池中ThreadLocal传递问题 Log4j2：高性能日志框架 MDC（Mapped Diagnostic Context）：日志诊断上下文 Spring Boot：快速集成 核心实现思路 1. 依赖配置 首先在项目中添加必要的依赖： <dependencies> &l....

线上系统出了问题，用户投诉接口响应慢，你登录到各个服务器查看日志，却发现日志信息杂乱无章，根本无法追踪一个请求从入口到出口的完整路径？或者一个请求跨越了多个微服务，每个服务都打印了自己的日志，但你无法将这些日志关联起来？ 这就是分布式系统日志追踪的经典难题。传统的日志记录方式已经无法满足微服务架构的需求。今天我们就来聊聊如何用SpringBoot + ELK + MDC构建一个完整的分布式日志追踪体系，让你能够快速定位跨服务调用链问题。