ONS客户端(1.7.0.Final)引发的log4j2日志丢失

事件起因：

由于统跳服务有“广播消息”的需求，而Redis的订阅功能在生产环境又需要进行配置白名单，对于首次接入的业务应用来说非常麻烦，

也加大运维扩容等操作的难度，遂打算引入阿里的MNS(消息服务)产品，几经确认，发现MNS并不支持“广播消息”功能，进而转向他们的ONS（消息队列）产品。

问题定位：

经过一系列不算繁杂的步骤后顺利接入ONS，开始进行数据验证的时候，问题就来了。ONS生产者、订阅者均能正常收发消息均正常，也满足“广播消息”到

多个实例的需求，刚要准备提测的时候，突然发现日志居然没打印，一开始以为是日志级别的问题，调整下日志级别，结果没其作用，接着便开始了漫长的

的无头绪DEBUG。几经波折，最后在其他同事（@许谋钧、@詹志彬）的帮助下找到问题所在，是由于ONS新版客户端会篡改LogContext的配置文件指向路径，

导致日志没有按照预期的进行输出。

排查过程：

联想到之前骨架是正常可以运行的，因此将苗头指向了新加入的 ONS客户端，发现去除ONS客户端的引用后日志就能正常打印，问题定位到ONS客户端。

1、打印日志容器的配置文件路径：

 

2、日志容器的配置文件路径变化：

 

由上图可以看出，一开始项目启动的时候是有正常的日志输出，日志配置文件路径指向也是正确的，是被后续某个地方给篡改了。

那么究竟是哪里给改动了？

3、项目与ONS客户端有发生交互的地方只有订阅者线程的启动，如下所示：

创建消费对象：

 

4、在创建对象的过程中，就会引用（ClientLogger）去创建自身的日志对象

 

5、继续查看源码发现其在创建日志对象时通过反射方法 调用 （Configurator 的 initialize）重新对配置文件进行重新设置，如下图所示。

 

 

解决方案：

方案一：通过修改 ONS客户端中 “rocketmq.client.log4j2.resource.fileName” 的指向来达到项目预期的日志输出格式；

方案二：降低客户端版本（1.7.0.Final  -->   1.2.4 ），较低版本中是没"log4j2_rocketmq_client.xml”的文件，也就不存在覆盖问题。

因为ONS客户端的引用需要包含在对外提供的jar包中，因此不可能强制要求引用者进行相应的日志设置，

因此选择“方案二”通过降低客户端版本号来解决该问题。

至此，前后历时两天的“日志丢失之谜”终于告一段落！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

谨以此文，提醒自己遇到问题，不要过于着急，抓住关键点后，沉下心走读源码，以便定位真正的问题所在！！！！！