都快2202年了，你还不会用RequestId看日志 ?

本文主要是介绍都快2202年了，你还不会用RequestId看日志 ?，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

引言

在日常的后端开发工作中，最常见的操作之一就是看日志排查问题，对于大项目一般使用类似ELK的技术栈统一搜集日志，小项目就直接把日志打印到日志文件。那不管对于大项目或者小项目，查看日志都需要通过某个关键字进行搜索，从而快速定位到异常日志的位置来进一步排查问题。

对于后端初学者来说，日志的关键字可能就是直接打印某个业务的说明加上业务标识，如果出现问题直接搜索对应的说明或者标识。例如下单场景，可能就直接打印:创建订单，订单编号:xxxx，当有问题的时候，则直接搜索订单编号或者创建订单。在这种方式下，经常会搜索出多条日志，增加问题的排查时长。

所以，今天我们就来说一说这个关键字的设计，这里我们使用RequestId进行精确定位问题日志的位置从而解决问题。

需求

目标： 帮助开发快速定位日志位置

思路：当前端进行一次请求的时候，在进行业务逻辑处理之前我们需要生成一个唯一的RequestId，在业务逻辑处理过程中涉及到日志打印我们都需要带上这个RequestId，最后响应给前端的数据结构同样需要带上RequestId。 这样，每次请求都会有一个RequestId，当某个接口异常则通过前端反馈的RequestId，后端即可快速定位异常的日志位置。

总结下我们的需求：

• 一次请求生成一次RequestId，并且RequestId唯一
• 一次请求响应给前端，都需要返回RequestId字段，接口正常、业务异常、系统异常，都需要返回该字段
• 一次请求在控制台或者日志文件打印的日志，都需要显示RequestId
• 一次请求的入参和出参都需要打印
• 对于异步操作，需要在异步线程的日志同样显示RequestId

实现

1. 实现生成和存储RequestId的工具类

public class RequestIdUtils {private static final ThreadLocal<UUID> requestIdHolder = new ThreadLocal<>();private RequestIdUtils() {}public static void generateRequestId() {requestIdHolder.set(UUID.randomUUID());}public static void generateRequestId(UUID uuid) {requestIdHolder.set(uuid);}public static UUID getRequestId() {return (UUID)requestIdHolder.get();}public static void removeRequestId() {requestIdHolder.remove();}
}

因为我们一次请求会生成一次RequestId，并且RequestId唯一，所以这里我们使用使用UUID来生成RequestId，并且用ThreadLocal进行存储。

1. 实现一个AOP，拦截所有的Controller的方法，这里是主要的处理逻辑

@Aspect
@Order
@Slf4j
public class ApiMessageAdvisor {@Around("execution(public * org.anyin.gitee.shiro.controller..*Controller.*(..))")public Object invokeAPI(ProceedingJoinPoint pjp) {String apiName = this.getApiName(pjp);// 生成RequestIdString requestId = this.getRequestId();// 配置日志文件打印 REQUEST_IDMDC.put("REQUEST_ID", requestId);Ob

这篇关于都快2202年了，你还不会用RequestId看日志 ?的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---