zipkin dubbo mysql_dubbo集成zipkin做链路追踪（二）

在上一篇文章中说到在springMVC、dubbo项目中成功集成了zipkin，并且使用也是正常，到zipkin控制台界面也可以看到所有的请求都链接起来了，这个是令人开心的。

但是在这个过程中遇到了很多问题，下面总结一下：

问题1

如何修改springMVC请求中的请求名称？

方法：brave默认用的是请求名称是请求方式，即get，post，put等；由源代码可以知道

public class DefaultSpanNameProvider implements SpanNameProvider {

public DefaultSpanNameProvider() {

}

public String spanName(HttpRequest request) {

return request.getHttpMethod();

}

}//从这个类中可以看到默认把请求方式作为这次请求的name

//自定义的requestAdapter类

package com.louie.trace;

import static com.github.kristofa.brave.IdConversion.convertToLong;

import java.util.ArrayList;

import java.util.Collection;

import java.util.List;

import com.github.kristofa.brave.KeyValueAnnotation;

import com.github.kristofa.brave.ServerRequestAdapter;

import com.github.kristofa.brave.SpanId;

import com.github.kristofa.brave.TraceData;

import com.github.kristofa.brave.http.BraveHttpHeaders;

import com.github.kristofa.brave.http.HttpServerRequest;

import com.github.kristofa.brave.http.SpanNameProvider;

public class CusHttpServerRequestAdapter implements ServerRequestAdapter {

private final HttpServerRequest request;

private final SpanNameProvider spanNameProvider;

private final String service;

private final String data;

public CusHttpServerRequestAdapter(HttpServerRequest request,String service,String data, SpanNameProvider spanNameProvider) {

this.request = request;

this.spanNameProvider = spanNameProvider;

this.service = service;

this.data = data;

}

public TraceData getTraceData() {

String sampled = request.getHttpHeaderValue(BraveHttpHeaders.Sampled.getName());

String parentSpanId = request.getHttpHeaderValue(BraveHttpHeaders.ParentSpanId.getName());

String traceId = request.getHttpHeaderValue(BraveHttpHeaders.TraceId.getName());

String spanId = request.getHttpHeaderValue(BraveHttpHeaders.SpanId.getName());

// Official sampled value is 1, though some old instrumentation send true

Boolean parsedSampled = sampled != null

? sampled.equals("1") || sampled.equalsIgnoreCase("true")

: null;

if (traceId != null && spanId != null) {

return TraceData.create(getSpanId(traceId, spanId, parentSpanId, parsedSampled));

} else if (parsedSampled == null) {

return TraceData.EMPTY;

} else if (parsedSampled.booleanValue()) {

// Invalid: The caller requests the trace to be sampled, but didn't pass IDs

return TraceData.EMPTY;

} else {

return TraceData.NOT_SAMPLED;

}

}

public String getSpanName() {

return spanNameProvider.spanName(request);//这里就是将默认的请求方式放进去，当然你可以手动修改成你需要的名字，例如请求的uri

}

public Collection requestAnnotations() {

KeyValueAnnotation sera = KeyValueAnnotation.create(

"service", service);

KeyValueAnnotation dataa = KeyValueAnnotation.create(

"data", data);

List kas = new ArrayList();

kas.add(sera);

kas.add(dataa);

return kas;

//return Collections..singleton(sera);

}

static SpanId getSpanId(String traceId, String spanId, String parentSpanId, Boolean sampled) {

return SpanId.builder()

.traceIdHigh(traceId.length() == 32 ? convertToLong(traceId, 0) : 0)

.traceId(convertToLong(traceId))

.spanId(convertToLong(spanId))

.sampled(sampled)

.parentId(parentSpanId == null ? null : convertToLong(parentSpanId)).build();

}

}

问题2

集成成功后，代码等没有报错，但是请求并没有串联起来，如下图

image.png

方法：这个是我遇到的问题，可能其他人不会遇到，毕竟环境不一样，先说说我的解决思路吧，刚开始一脸懵逼状态，明明是按照demo搞的，为什么人家的正常，自己的不正常；

首先：我去将别人的demo下载下来，还好demo不需要搞数据库等等东西，然后我配置了下zk等，跑起来了；测试了下，如愿以偿，跟我想要的一样，那么问题来了，为什么我的没有串起来，他的请求反倒可以呢；

第二步：对比两个项目中这部分配置有什么不一样的，经过一遍又一遍的对比，我发现了demo中直接通过spi配置了filter，dubbo的xml配置文件中并没有重新再去配置filter，但是我的项目中我是有在xml中配置了filter，然后就是这里的区别导致了请求没有串联起来，那么我去掉这个配置试试看，结果发现一切正常，由此可知问题是出在这里；

第三步：既然知道了问题出在这里，那么就得去找到为什么这样配置会错误，然后去了解一下dubbo的spi机制已经过滤器的顺序，粗略了解了一下，加上@Activate注解的类，dubbo会将该类作为默认的过滤器来加载，不用再继续到xml文件中配置，假如在xml文件中配置的话，这个过滤器的加载顺序将按照配置的加载顺序来执行，具体修改执行顺序的话，请自行百度。这里dubbo的spi机制非常灵活。

第四步：那么为什么作为默认加载的话没有问题，然后将过滤器放入xml文件中的话就出现了这种问题，但是我在提供者这边也配置了xml，但是提供者这边却没有任何问题，这个就很奇怪了，打断点调试查看源代码，可以发现最终取的span是从ThreadLocal中拿出来，加与不加xml配置的区别在于从ThreadLocal做这个类型对象中能否取到值，结果是加了的取出来的值为null，不加的时候取出来是上一次请求的span，由此可知原因出在这里，再仔细查询发现用的ThreadLocal对象并不是同一个，同时又确认问题不是出在dubbo框架，大胆猜测，可能是filter的顺序导致的问题；

第五步：重新配置filter的顺序，将自定义的traceFilterc定义到第一个后，启动调试，发现正常，然后将traceFilterc定义到最后一个后发现出现之前的问题，好了找到原因了。一个个测试，可以发现是自己其他定义的filter影响的，因为在我们项目中有用到一个熔断器的fiter，当将traceFilterc配置在该熔断器后，就出现问题，在之前就没有任何问题。

第六步：同事跟我说明了这个熔断器的原理，里面有一个线程池，来进行请求，导致client进来的请求跟rpc调用的请求不是同一个，然后导致ThreadLocal对象也不是同一个，由此不能串联起来。那么知道原因了在测试一把，打印一下各自的线程名称，发现永远都不会一样。自此该问题结束。

问题3

如何过滤请求记录中的相关参数，因为我们项目中涉及到一些很大的字段，如果将其全部发到zipkin的话感觉不太好，并且这些打字段对查找问题意义不大，所有引出这个问题。

方法：供大家自己实现，我目前也想不到什么好办法，哈哈哈哈，如果有好方法的话希望大家能交流一下，谢谢

如果帮到您了，请点个喜欢，谢谢！;