log4j2之ThreadContext

系统中使用log4j2作为日志系统,然而在高并发的情况下,多次请求的日志参杂在一起,要跟踪某个用户一次的请求操作所有日志是很麻烦的。幸运的是log4j中有相应的解决方案。

NDC(Nested Diagnostic Context)和MDC(Mapped Diagnostic Context)是log4j种非常有用的两个类,它们用于存储应用程序的上下文信息(context infomation),从而便于在log中使用这些上下文信息。NDC采用了一个类似栈的机制来push和pop上下文信息,每一个线程都独立地储存上下文信息。比如说一个servlet就可以针对每一个request创建对应的NDC,储存客户端地址等等信息。MDC和NDC非常相似,所不同的是MDC内部使用了类似map的机制来存储信息,上下文信息也是每个线程独立地储存,所不同的是信息都是以它们的key值存储在”map”中。

NDC和MDC的原理是用了java的ThreadLocal类。可以针对不同线程存储信息。但是今天在log4j2上使用时发现没有找到NDC和MDC。查找官方文档,原来是换成了ThreadContext。操作也挺简单:


关闭使用CloseableThreadContext:



在输出格式中引用使用:
Use %X by itself to include the full contents of the Map.
Use %X{key} to include the specified key.
Use %x to include the full contents of the Stack.

官方文档地址:Log4j 2 API Thread Context

PS:今天发现系统在并发时MySQL数据库CPU占用近100%的问题。之前有跑过大交易,CPU占用在50%上下。思来想去,并没有找到确切的原因。决定先写一个并发测试工具,配合日志优化,监测情况。最近忙着把rmi和zookeeper整合,弄完就会优化缓存。目前系统只是小范围使用ehcache,目前来看并没有什么问题。分布式用redis,本地用ehcace。阿里云的数据库高配版不便宜,能用技术流解决的问题就不要花银子堆机器了。记得之前国外有大神用一台简单的服务器支撑了上百万的访问题。虽然应用场景不同,但是我们目前机器的性能不应如此,还可以做到更多的支撑。


已发布

分类

,

来自

标签:

评论

《“log4j2之ThreadContext”》 有 4 条评论

  1. 匿名

    你这个ps和log4j2的配置有关系?

    1. wangzhengzhen

      嗯,就像巴基斯坦和卡巴斯基的关系

  2. kevin

    看了博主文章,决定收藏了这个站点。
    老夫敲代码,从来不分前端、后端、移动端。一把梭,拿起键盘就是干!

    1. wangzhengzhen

      相互学习,多多交流

回复 wangzhengzhen 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注