Logback日志跨线程追踪实践

Logback日志跨线程追踪实践

当我们程序在服务器上面跑的时候,是不是很多时候很难定位问题? 当一大堆繁杂的日志文件丢给你的时候,你如何能从中定位到问题? 本项目源码已经上传Github: https://github.com/liushunqiu/log-track

1. 自定义日志模板参数:Logback的Pattern模板

当一个请求过来,我们想要知道当前请求具体跑了那些流程该怎么做呢? 噔噔噔噔..我们的男主Logback自定义Pattern模板即将登场.


在我们打印日志的时候,通常我们都会把一些重要的参数信息写到日志里面,方便我们后期从日志里面定位问题,其他的内部系统调用我们的程序的时候,我们可以要求他们那边在header头里面增加trace-id这样的唯一标识,如果没有该参数的话,我们自己手动生成一个唯一的标识,方便我们将整条请求链路构建起来.

<property name="CONSOLE_LOG_PATTERN"
            value="[%yellow(%date{yyyy-MM-dd HH:mm:ss})] [%highlight(%-5level)] [%cyan(%traceId)] [%magenta(%thread)] [%blue(%file:%line)] [%green(%logger)] : %.4000m%n"/>

上面这里是Logback的定义变量,重点关注[%cyan(%traceId)]这个参数(ps:其他的日志系统如log4j2都有类似的实现)  项目结构

要实现让Logback识别我们自定义的标识符,我们需要继承两个方法ClassicConverterPatternLayout,具体实现如下:

public class PatternLogbackLayout extends PatternLayout {
  static {
    defaultConverterMap.put("traceId", TraceIdPatternConverter.class.getName());
  }
}

public class TraceIdPatternConverter extends ClassicConverter {
	@Override
	public String convert(ILoggingEvent iLoggingEvent) {
		String traceId = LogHandlerInterceptor.getTrack();
		return StringUtils.isEmpty(traceId) ? "traceId" : traceId;
	}
}

通过spring的拦截器我们将请求的header头里面的参数赋值给traceId,然后配置logback.xml,让logback去识别我们定义的traceId

<appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
   <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
      <layout class="com.blacksearch.logback.PatternLogbackLayout">
      	<pattern>${CONSOLE_LOG_PATTERN}</pattern>
      </layout>
   </encoder>
</appender>

通过以上配置,我们已经可以在日志里面看到traceId了

[2019-05-10 16:47:38] [INFO ] [538e2c0d-3800-4c86-b320-260bdd945c0c] [http-nio-8080-exec-6] [TestLogTrackController.java:15] [com.blacksearch.controller.TestLogTrackController] : 测试
[2019-05-10 16:47:38] [DEBUG] [538e2c0d-3800-4c86-b320-260bdd945c0c] [http-nio-8080-exec-6] [AbstractMessageConverterMethodProcessor.java:298] [org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor] : Nothing to write: null body

这样子在服务器上面我们可以通过

grep '538e2c0d-3800-4c86-b320-260bdd945c0c'

查看到当前请求的所有日志~或者上ELK之后 直接搜索538e2c0d-3800-4c86-b320-260bdd945c0c 方便开心~

2. 当我们使用多线程的时候,我们发现,原先定义的标识居然消失了!!!

解决方案:自定义抽象类实现Runnable 首先我们先来复现问题. eg:

@RequestMapping("/asynLogTrack")
public String asynLogTrack(){
	logger.info("ces--------");
	new Thread(new Runnable() {
		@Override
		public void run() {
			logger.info("ces");
		}
	}).start();
	return null;
}
[2019-05-10 16:55:18] [INFO ] [5b446567-97be-42f7-b6b0-205a6b431e87] [http-nio-8080-exec-2] [TestLogTrackController.java:21] [com.blacksearch.controller.TestLogTrackController] : ces--------
[2019-05-10 16:55:18] [INFO ] [traceId] [Thread-10] [TestLogTrackController.java:25] [com.blacksearch.controller.TestLogTrackController] : ces
[2019-05-10 16:55:18] [DEBUG] [5b446567-97be-42f7-b6b0-205a6b431e87] [http-nio-8080-exec-2] [AbstractMessageConverterMethodProcessor.java:298] [org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor] : Nothing to write: null body

我们看到打印 ces 的打印记录,我们发现,traceId居然丢失了!!! 原因在于,栈是线程私有,当我们新建线程的时候,新建的线程跟原来的线程互相独立,也就是说logback无法在新建的线程上获取到值。既然如何,那么我们该如何让Logback在新线程上获取到值呢?正如标题而言。

public abstract class TrackRunnable implements Runnable {

	public abstract void trackRun();

	private String track = LogHandlerInterceptor.getTrack();

	@Override
	public void run() {
		try {
			LogHandlerInterceptor.setTrace(track);
			trackRun();
		}finally {
			LogHandlerInterceptor.remove();
		}
	}
}

我们采用抽象类实现Runnable,然后在run()方法里面通过ThreadLocal去重新赋值。eg:

@RequestMapping("/asynLogTrackHasTrace")
public String asynLogTrackHasTrace(){
	logger.info("ces1------");
	new Thread(new TrackRunnable() {
		@Override
		public void trackRun() {
			try {
				Thread.sleep(4000);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
			logger.info("ces2-----------");
		}
	}).start();
	return null;
}
[2019-05-10 17:07:20] [INFO ] [0a7f30d3-8e1d-49b4-9bca-4b72fd1c0ccd] [http-nio-8080-exec-5] [TestLogTrackController.java:33] [com.blacksearch.controller.TestLogTrackController] : ces1------
[2019-05-10 17:07:20] [DEBUG] [0a7f30d3-8e1d-49b4-9bca-4b72fd1c0ccd] [http-nio-8080-exec-5] [AbstractMessageConverterMethodProcessor.java:298] [org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor] : Nothing to write: null body
[2019-05-10 17:07:20] [DEBUG] [traceId] [http-nio-8080-exec-5] [FrameworkServlet.java:1130] [org.springframework.web.servlet.DispatcherServlet] : Completed 200 OK
[2019-05-10 17:07:24] [INFO ] [0a7f30d3-8e1d-49b4-9bca-4b72fd1c0ccd] [Thread-11] [TestLogTrackController.java:42] [com.blacksearch.controller.TestLogTrackController] : ces2-----------

完美解决问题~ 以上代码已经上传到同性交友网站~欢迎各位看官拍砖~

黑搜丶D

转载于:https://my.oschina.net/u/4131421/blog/3048221

### Java 中通过日志输出追踪线程 ID 的实现方式 在 Java 应用程序中,可以通过多种框架和工具来实现在日志输出中包含线程 ID 功能。以下是几种常见的实现方式及其具体细节: #### 使用 Log4j 1.x 配置线程 ID Log4j 提供了一种简单的方法,在其 `PatternLayout` 中支持 `%t` 占位符用于表示当前执行的日志记录的线程名称[^2]。如果需要更精确地控制线程标识,则可以扩展此功能。 ```xml <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%-5p [%t:%tid] %d{yyyy-MM-dd HH:mm:ss} %c - %m%n"/> </layout> ``` 上述配置中的 `[%-5p [%t:%tid]]` 表达式会将优先级、线程名以及时间戳等信息一并打印出来。然而需要注意的是,默认情况下 Log4j 并不提供内置的线程 ID 支持,因此可能需进一步定制化解决方案。 #### 自定义 LoggingEvent 和 Logger 子类 (适用于高级需求) 对于更加复杂的场景,比如希望在线程级别上附加额外元数据或者完全替代默认行为时,可以选择继承现有的 API 来构建自定义逻辑。例如创建名为 MyLoggingEvent 及 MyLogger 类型的对象实例,并重写相应方法以便于捕获到实际运行期间产生的 Thread.currentThread().getId() 值[^3]。 ```java public class MyLoggingEvent extends LoggingEvent { private long threadId; public MyLoggingEvent(String fqnOfCategoryClass, Category cat, Priority level, Object message, ThrowableInformation ti, String ndc, LocationInfo locationInfo) { super(fqnOfCategoryClass, cat, level, message, ti, ndc, locationInfo); this.threadId = Thread.currentThread().getId(); } @Override public void format(CustomFormatter formatter){ // Add custom formatting here including thread id. StringBuilder sb=new StringBuilder(super.getMessage()); sb.append(",ThreadId=").append(this.threadId); super.setMessage(sb.toString()); } } ``` 随后更新原有 logger 定义部分替换为新版本组件即可完成改造过程。 #### 利用 MDC/NDC 实现 Trace Id 注入 另一种常见做法涉及借助 Mapped Diagnostic Context(MDC) 或 Nested Diagnostic Context(NDC),它们允许开发者向每次请求关联特定上下文变量(如 trace-id),从而便于后续分析定位问题所在位置[^4]^[]^。下面给出基于 SLF4J + Logback 组合的一个例子演示如何动态注入全局唯一标识符(UUID): ```java import org.slf4j.MDC; import java.util.UUID; // At the start of request handling or task execution MDC.put("traceId", UUID.randomUUID().toString()); try{ LOGGER.info("This is a sample log entry with traceId."); }catch(Exception e){ LOGGER.error("An error occurred.",e); }finally{ MDC.clear(); // Clean up after use to prevent memory leaks } ``` 与此同时调整对应的 XML 文件布局描述如下所示: ```xml <pattern>%date %-5level [%thread][%X{traceId}] %logger{36} - %msg%n</pattern> ``` 这样每条生成的消息都会自动携带独一无二的跟踪编号字段(%X{}),方便排查跨服务调用链路状况等问题发生原因。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值