很多互联网公司都用的dubbo分布式框架进行微服务的开发，一个大系统往往会被拆分成很多不同的子系统，并且子系统还会部署多台机器，当其中一个系统出问题了，查看日志十分麻烦

所以我们需要一个固定的流程ID和机器ip地址等来把所有的日志穿起来，当然可以通过调用其他接口时参数进行传递，但是这样子对代码的耦合性太强，对代码有侵入性。

我们可以通过dubbo的filter 结合slf4j的MDC或者log4j2的ThreadContext的进行参数的注入，可以直接在日志文件中配置被注入的参数，这样就对系统和日志id打印进行了解耦。

其中当用logback日志的时候是需要调用MDC的方法，而log4j2则需要调用ThreadContext的方法。

当然我们可以直接默认指定使用logback日志，当使用log4j2日志的时候，在启动虚拟机时候可以加载一个参数(-Dlogging.type=log4j2)，然后通过System.getProperty(“logging.type”)获取出使用的日志类型进行判断，从而选择使用MDC还是ThreadContext。

上游系统调用下游系统和下游系统接收上游系统定义两个filter

@Activate(group = { Constants.CONSUMER })

@Activate(group = { Constants.PROVIDER })

下游系统被调用的时候可以通过dubbo中RpcContext的getAttachment方法来获取上游系统传递下来的值

String rid = RpcContext.getContext().getAttachment("TRACE_ID");

并且根据判断来使用MDC还是ThreadContext

String logType = System.getProperty("logging.type");

ThreadContext.put(key,val);
//或者
MDC.put(key, val);

result = invoker.invoke(invocation);

在方法调用完成后移除该ID

//放到try中
result = invoker.invoke(invocation);

//放在finally块中
ThreadContext.remove(key);
或者
MDC.remove(key);

当上游系统调用下游系统的时候，可以通过dubbo中RpcContext的setAttachment方法进行参数传递

RpcContext.getContext().setAttachment("TRACE_ID", id);
Result result = invoker.invoke(invocation);

以后只需要在dubbo工程中引入包，然后在resources的META-INF.dubbo的com.alibaba.dubbo.rpc.Filter文件中配置filter就行，然后在日志文件中用${trace_id} 即可获取打印日志id

当然如果想打印ip只需要使用com.alibaba.dubbo.common.utils.NetUtils工具获取ip,然后put到MDC或者ThreadContext里面

String ip = NetUtils.getLocalHost()

最后通过ELK对日志进行收集，到时候就能很快的定位到错误位置。当然也可以结合ElasticAlert进行错误日志报警。

注意：多线程的情况下，会取不到这个ID，需要自己做处理，比如将创建线程的时候将id通过参数传入（见：Dubbo分布式日志追踪,多线程不能获取窜ID和IP问题）