SpringBoot如何快速过滤出一次请求的所有日志？
前言
在现网出现故障时，我们经常需要获取一次请求流程里的所有日志进行定位。如果请求只在一个线程里处理，则我们可以通过线程id来过滤日志，但如果请求包含异步线程的处理，那么光靠线程id就显得捉襟见肘了。
华为iot平台，提供了接收设备上报数据的能力， 当数据到达平台后，平台会进行一些复杂的业务逻辑处理，如数据存储，规则引擎，数据推送，命令下发等等。由于这个逻辑之间没有强耦合的关系，所以通常是异步处理。如何将一次数据上报请求中包含的所有业务日志快速过滤出来，就是本文要介绍的。
正文
slf4j日志框架提供了一个mdc(mapped diagnostic contexts)工具类，谷歌翻译为映射的诊断上下文，从字面上很难理解，我们可以先实战一把。
public class main { private static final string key = requestid; private static final logger logger = loggerfactory.getlogger(main.class); public static void main(string[] args) { // 入口传入请求id mdc.put(key, uuid.randomuuid().tostring()); // 打印日志 logger.debug(log in main thread 1); logger.debug(log in main thread 2); logger.debug(log in main thread 3); // 出口移除请求id mdc.remove(key); }}
我们在main函数的入口调用mdc.put()方法传入请求id，在出口调用mdc.remove()方法移除请求id。配置好log4j2.xml文件后，运行main函数，可以在控制台看到以下日志输出：
2018-02-17 1352.606 {requestid=f97ea0fb-2a43-40f4-a3e8-711f776857d0} [main] debug cn.wudashan.main - log in main thread 12018-02-17 1352.609 {requestid=f97ea0fb-2a43-40f4-a3e8-711f776857d0} [main] debug cn.wudashan.main - log in main thread 22018-02-17 1352.609 {requestid=f97ea0fb-2a43-40f4-a3e8-711f776857d0} [main] debug cn.wudashan.main - log in main thread 3
从日志中可以明显地看到花括号中包含了（映射的）请求id(requestid)，这其实就是我们定位（诊断）问题的关键字（上下文）。有了mdc工具，只要在接口或切面植入put()和remove()代码，在现网定位问题时，我们就可以通过grep requestid=xxx *.log快速的过滤出某次请求的所有日志。
进阶
然而，mdc工具真的有我们所想的这么方便吗？回到我们开头，一次请求可能涉及多线程异步处理，那么在多线程异步的场景下，它是否还能正常运作呢？talk is cheap, show me the code。
public class main { private static final string key = requestid; private static final logger logger = loggerfactory.getlogger(main.class); public static void main(string[] args) { // 入口传入请求id mdc.put(key, uuid.randomuuid().tostring()); // 主线程打印日志 logger.debug(log in main thread); // 异步线程打印日志 new thread(new runnable() { @override public void run() { logger.debug(log in other thread); } }).start(); // 出口移除请求id mdc.remove(key); }}
代码里我们新起了一个异步线程，并在匿名对象runnable的run()方法打印日志。运行main函数，可以在控制台看到以下日志输出：
2018-02-17 1443.487 {requestid=e6099c85-72be-4986-8a28-de6bb2e52b01} [main] debug cn.wudashan.main - log in main thread2018-02-17 1443.490 {} [thread-1] debug cn.wudashan.main - log in other thread
不幸的是，请求id在异步线程里不打印了。这是怎么回事呢？要解决这个问题，我们就得知道mdc的实现原理。
由于篇幅有限，这里就暂不详细介绍，mdc之所以在异步线程中不生效是因为底层采用threadlocal作为数据结构，我们调用mdc.put()方法传入的请求id只在当前线程有效。感兴趣的小伙伴可以自己深入一下代码细节。
知道了原理那么解决这个问题就轻而易举了，我们可以使用装饰器模式，新写一个mdcrunnable类对runnable接口进行一层装饰。在创建mdcrunnable类时保存当前线程的mdc值，在执行run()方法时再将保存的mdc值拷贝到异步线程中去。
代码实现如下：
public class mdcrunnable implements runnable { private final runnable runnable; private final map map; public mdcrunnable(runnable runnable) { this.runnable = runnable; // 保存当前线程的mdc值 this.map = mdc.getcopyofcontextmap(); } @override public void run() { // 传入已保存的mdc值 for (map.entry entry : map.entryset()) { mdc.put(entry.getkey(), entry.getvalue()); } // 装饰器模式，执行run方法 runnable.run(); // 移除已保存的mdc值 for (map.entry entry : map.entryset()) { mdc.remove(entry.getkey()); } } }
接着，我们需要对main函数里创建的runnable实现类进行装饰：
public class main { private static final string key = requestid; private static final logger logger = loggerfactory.getlogger(main.class); private static final executorservice executor = executors.newsinglethreadexecutor(); public static void main(string[] args) { // 入口传入请求id mdc.put(key, uuid.randomuuid().tostring()); // 主线程打印日志 logger.debug(log in main thread); // 异步线程打印日志，用mdcrunnable装饰runnable new thread(new mdcrunnable(new runnable() { @override public void run() { logger.debug(log in other thread); } })).start(); // 异步线程池打印日志，用mdcrunnable装饰runnable executor.execute(new mdcrunnable(new runnable() { @override public void run() { logger.debug(log in other thread pool); } })); executor.shutdown(); // 出口移除请求id mdc.remove(key); }}
执行main函数，将会输出以下日志：
2018-03-04 2305.343 {requestid=5ee2a117-e090-41d8-977b-cef5dea09d34} [main] debug cn.wudashan.main - log in main thread2018-03-04 2305.346 {requestid=5ee2a117-e090-41d8-977b-cef5dea09d34} [thread-1] debug cn.wudashan.main - log in other thread2018-03-04 2305.347 {requestid=5ee2a117-e090-41d8-977b-cef5dea09d34} [pool-2-thread-1] debug cn.wudashan.main - log in other thread pool
congratulations！经过我们的努力，最终在异步线程和线程池中都有requestid打印了！
总结
本文讲述了如何使用mdc工具来快速过滤一次请求的所有日志，并通过装饰器模式使得mdc工具在异步线程里也能生效。有了mdc，再通过aop技术对所有的切面植入requestid，就可以将整个系统的任意流程的日志过滤出来。
使用mdc工具，在开发自测阶段，可以极大地节省定位问题的时间，提升开发效率；在运维维护阶段，可以快速地收集相关日志信息，加快分析速度。
示例源码地址：https://github.com/wudashan/slf4j-mdc-muti-thread
三级钟MEMS振荡器的性能特点和优势
怎样利用人工智能让双11变得更加高效
如何意念操控,脑波技术+VR/AR教你怎么玩
DEKRA德凯深度参与IEC/EN TC21/SC21A电池标准委员会专家组讨论
11月11日在线研讨会 | Excel诊断调查问卷与ODX的转换及应用
SpringBoot如何快速过滤出一次请求的所有日志？
压力传感器常见问题解答
利用I2C通信接口实现测温的设计方案
充电芯片烧毁竟是电池热插拔惹的祸？
MS2609—兼容全频段，全制式导航低噪声放大器，参数兼容CKRF3509
土壤pH速测仪产品介绍
Fluke PTi120 便携式口袋热像仪的功能作用及特点分析
Model X出现安全漏洞,特斯拉表示正在修补
智能制造和生命科技企业东湖高新发布2022第一季度报告
中国信科提供一系列的“5G+”业务，为5G在垂直行业的应用指明方向
海尔净水将在国庆期间打造一场关于物联网水场景的消费盛宴
怎样做到高清数字电视及流媒体播放一体化
TCMalloc 的架构设计细节
今年汽车芯片为什么短缺
用于记录仪接口的可编程放大器
在现网出现故障时，我们经常需要获取一次请求流程里的所有日志进行定位。如果请求只在一个线程里处理，则我们可以通过线程id来过滤日志，但如果请求包含异步线程的处理，那么光靠线程id就显得捉襟见肘了。
华为iot平台，提供了接收设备上报数据的能力， 当数据到达平台后，平台会进行一些复杂的业务逻辑处理，如数据存储，规则引擎，数据推送，命令下发等等。由于这个逻辑之间没有强耦合的关系，所以通常是异步处理。如何将一次数据上报请求中包含的所有业务日志快速过滤出来，就是本文要介绍的。
正文
slf4j日志框架提供了一个mdc(mapped diagnostic contexts)工具类，谷歌翻译为映射的诊断上下文，从字面上很难理解，我们可以先实战一把。
public class main { private static final string key = requestid; private static final logger logger = loggerfactory.getlogger(main.class); public static void main(string[] args) { // 入口传入请求id mdc.put(key, uuid.randomuuid().tostring()); // 打印日志 logger.debug(log in main thread 1); logger.debug(log in main thread 2); logger.debug(log in main thread 3); // 出口移除请求id mdc.remove(key); }}
我们在main函数的入口调用mdc.put()方法传入请求id，在出口调用mdc.remove()方法移除请求id。配置好log4j2.xml文件后，运行main函数，可以在控制台看到以下日志输出：
2018-02-17 1352.606 {requestid=f97ea0fb-2a43-40f4-a3e8-711f776857d0} [main] debug cn.wudashan.main - log in main thread 12018-02-17 1352.609 {requestid=f97ea0fb-2a43-40f4-a3e8-711f776857d0} [main] debug cn.wudashan.main - log in main thread 22018-02-17 1352.609 {requestid=f97ea0fb-2a43-40f4-a3e8-711f776857d0} [main] debug cn.wudashan.main - log in main thread 3
从日志中可以明显地看到花括号中包含了（映射的）请求id(requestid)，这其实就是我们定位（诊断）问题的关键字（上下文）。有了mdc工具，只要在接口或切面植入put()和remove()代码，在现网定位问题时，我们就可以通过grep requestid=xxx *.log快速的过滤出某次请求的所有日志。
进阶
然而，mdc工具真的有我们所想的这么方便吗？回到我们开头，一次请求可能涉及多线程异步处理，那么在多线程异步的场景下，它是否还能正常运作呢？talk is cheap, show me the code。
public class main { private static final string key = requestid; private static final logger logger = loggerfactory.getlogger(main.class); public static void main(string[] args) { // 入口传入请求id mdc.put(key, uuid.randomuuid().tostring()); // 主线程打印日志 logger.debug(log in main thread); // 异步线程打印日志 new thread(new runnable() { @override public void run() { logger.debug(log in other thread); } }).start(); // 出口移除请求id mdc.remove(key); }}
代码里我们新起了一个异步线程，并在匿名对象runnable的run()方法打印日志。运行main函数，可以在控制台看到以下日志输出：
2018-02-17 1443.487 {requestid=e6099c85-72be-4986-8a28-de6bb2e52b01} [main] debug cn.wudashan.main - log in main thread2018-02-17 1443.490 {} [thread-1] debug cn.wudashan.main - log in other thread
不幸的是，请求id在异步线程里不打印了。这是怎么回事呢？要解决这个问题，我们就得知道mdc的实现原理。
由于篇幅有限，这里就暂不详细介绍，mdc之所以在异步线程中不生效是因为底层采用threadlocal作为数据结构，我们调用mdc.put()方法传入的请求id只在当前线程有效。感兴趣的小伙伴可以自己深入一下代码细节。
知道了原理那么解决这个问题就轻而易举了，我们可以使用装饰器模式，新写一个mdcrunnable类对runnable接口进行一层装饰。在创建mdcrunnable类时保存当前线程的mdc值，在执行run()方法时再将保存的mdc值拷贝到异步线程中去。
代码实现如下：
public class mdcrunnable implements runnable { private final runnable runnable; private final map map; public mdcrunnable(runnable runnable) { this.runnable = runnable; // 保存当前线程的mdc值 this.map = mdc.getcopyofcontextmap(); } @override public void run() { // 传入已保存的mdc值 for (map.entry entry : map.entryset()) { mdc.put(entry.getkey(), entry.getvalue()); } // 装饰器模式，执行run方法 runnable.run(); // 移除已保存的mdc值 for (map.entry entry : map.entryset()) { mdc.remove(entry.getkey()); } } }
接着，我们需要对main函数里创建的runnable实现类进行装饰：
public class main { private static final string key = requestid; private static final logger logger = loggerfactory.getlogger(main.class); private static final executorservice executor = executors.newsinglethreadexecutor(); public static void main(string[] args) { // 入口传入请求id mdc.put(key, uuid.randomuuid().tostring()); // 主线程打印日志 logger.debug(log in main thread); // 异步线程打印日志，用mdcrunnable装饰runnable new thread(new mdcrunnable(new runnable() { @override public void run() { logger.debug(log in other thread); } })).start(); // 异步线程池打印日志，用mdcrunnable装饰runnable executor.execute(new mdcrunnable(new runnable() { @override public void run() { logger.debug(log in other thread pool); } })); executor.shutdown(); // 出口移除请求id mdc.remove(key); }}
执行main函数，将会输出以下日志：
2018-03-04 2305.343 {requestid=5ee2a117-e090-41d8-977b-cef5dea09d34} [main] debug cn.wudashan.main - log in main thread2018-03-04 2305.346 {requestid=5ee2a117-e090-41d8-977b-cef5dea09d34} [thread-1] debug cn.wudashan.main - log in other thread2018-03-04 2305.347 {requestid=5ee2a117-e090-41d8-977b-cef5dea09d34} [pool-2-thread-1] debug cn.wudashan.main - log in other thread pool
congratulations！经过我们的努力，最终在异步线程和线程池中都有requestid打印了！
总结
本文讲述了如何使用mdc工具来快速过滤一次请求的所有日志，并通过装饰器模式使得mdc工具在异步线程里也能生效。有了mdc，再通过aop技术对所有的切面植入requestid，就可以将整个系统的任意流程的日志过滤出来。
使用mdc工具，在开发自测阶段，可以极大地节省定位问题的时间，提升开发效率；在运维维护阶段，可以快速地收集相关日志信息，加快分析速度。
示例源码地址：https://github.com/wudashan/slf4j-mdc-muti-thread
三级钟MEMS振荡器的性能特点和优势
怎样利用人工智能让双11变得更加高效
如何意念操控,脑波技术+VR/AR教你怎么玩
DEKRA德凯深度参与IEC/EN TC21/SC21A电池标准委员会专家组讨论
11月11日在线研讨会 | Excel诊断调查问卷与ODX的转换及应用
SpringBoot如何快速过滤出一次请求的所有日志？
压力传感器常见问题解答
利用I2C通信接口实现测温的设计方案
充电芯片烧毁竟是电池热插拔惹的祸？
MS2609—兼容全频段，全制式导航低噪声放大器，参数兼容CKRF3509
土壤pH速测仪产品介绍
Fluke PTi120 便携式口袋热像仪的功能作用及特点分析
Model X出现安全漏洞,特斯拉表示正在修补
智能制造和生命科技企业东湖高新发布2022第一季度报告
中国信科提供一系列的“5G+”业务，为5G在垂直行业的应用指明方向
海尔净水将在国庆期间打造一场关于物联网水场景的消费盛宴
怎样做到高清数字电视及流媒体播放一体化
TCMalloc 的架构设计细节
今年汽车芯片为什么短缺
用于记录仪接口的可编程放大器