常见问题
- 1.spring.zipkin.enabled的作用和spring.sleuth.enabled的作用
这两个配置默认都是true，对client端而言，只要pom添加了依赖，默认就是开启了链路跟踪功能，但是两者是互斥的，也就是说任意情况下只有一个会生效：
在使用http发送时，spring.zipkin.enabled=false则可以关闭跟踪功能;
在使用消息队列发送时(如kafka/rabbitmq)，spring.sleuth.enabled=false则可以关闭跟踪功能;
为什么说两者互斥呢，因为client只能选择一种方式发送调用链路信息给server端，HTTP或者消息队列，使用http的话，依赖的pom是
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-sleuth-zipkin</artifactId>
</dependency>
此时spring.zipkin.enabled配置是有效的，可以用来做开关，
如果使用消息队列，如kafka，那么pom依赖是
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-sleuth-zipkin-stream</artifactId>
<exclusions>
<exclusion>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-server</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-stream-kafka</artifactId>
</dependency>
这种情况下spring.zipkin.enabled这个配置是没有用的，在idea的application.poroperties可以点不开，上面的情况则可以点开，这时候使用spring.sleuth.enabled配置来关闭功能；
注意这个配置：spring.sleuth.sampler.percentage = 1
他默认是0.1，也就是手机10%的信息，如果你没有设置，那么只有10%左右的信息会发送到server端，因此可能看不到，注意自己测试时可以设置固定的1，便于检验效果，另外如果使用消息队列，记得server注解要修改为@EnableZipkinStreamServer，否则读不到kafka的消息，使用http的方式是@EnableZipkinServer注解
使用ES存储貌似有这个问题，在zipkin server的页面的dependency看不到服务之间的调用信息，需要执行一个插件zipkin-dependency.jar，但是执行之后，后面再生成新的调用信息，在dependency里面照样没有，比如调用次数还是旧的次数，也就是说不能实时，有点坑爹
- 4.使用kafka的方式，不配置kafka地址导致工程启动失败
client使用kafka的方式发送信息到server端，我么你看pom，发现引入了，starter-sleuth，sleuth-zipkin-stream，stream-kafka这几个包，类似的意思就是引入了sleuth，将zipkin的调用信息封装到sleuth，然后将sleuth转换成stream，然后stream绑定到kafka，这些都是springcloud本身封装好的，用起来很简单，但是问题是，client端引入了这些信息之后，意味着必须在配置文件中配置kafka的地址，而且不能乱配，要是有效，可用的kafka地址，否则工程启动的时候，就会因为连接kafka失败而启动失败。如果说必须要用这个组件拿到没关系，但是如果说什么时候你不想跟踪信息了，那怎么办？删除pom吗？那就意味着改代码。换言之这样不灵活的地方在于，这个功能不是可选的了，而是必须的了，不配地址启动不了。
这里处理有这么几个思路：
1.检查启动失败的报错信息，知道是在初始化OutputBindingLifecycle这个类的时候抛出了异常，可以通过反射将抛出异常的那段代码的条件设置为true，因此就会跳过那段抛异常的代码，这样工程就可以启动了，
2.那么接下来的问题就是，程序能够启动，但是spring.sleuth.enabled默认是开启的，等下程序被调用的时候，肯定会尝试去发送调用信息到kfaka，但是这时候根本没有配置kafak，这时候程序会尝试再次发送，打印出很多error日志。因此这里面可以把这个配置给它弄成默认false，通过实现EnvironmentPostProcessor接口，在程序启动的时候，修改spring.sleuth.enabled的属性，在修改之前查询配置信息，如程序配置了，那么久不做什么，程序配true那就让他true，配的false那就让他false，但是如果没有配置(null)，或者其他的值，那么我们就设置一下，将spring.sleuth.enabled属性的值设置为false，这样程序启动之后，就不会去发送链路跟踪信息到kafak了，
这样，在我们没有配置kafka地址的情况下，程序也能起来，并且也不会打出很多错误的日志了。
3.关于第2点的error日志，我自己在搭建的时候，有两个工程，发现一个工程在发送失败之后就不再尝试发送了，只打印一次error日志，这个最好了，反正kafka确实连接不上（kafka挂了或者程序没有配置kafka地址但是却把spring.sleuth.enabled设置为true），但是另一个工程却不停的打印error日志，1秒一次，好像不停的重试，这就不好了，这样日志太多了，我找到报错的类，发现两个工程打印错误信息的类有一定不同，代码行数差两行，经过很久的排查，发现不停的打印error的是springboot1.5.6版本，只打印一次的是springcloud1.5.8版本，里面依赖的是spring——integration-core这个组件，一个是4.3.11 一个是4.3.12版本，4.3.12版本的只打印一次error，对比代码发现有一些不同，估计是在4.3.12版本修复了这个问题，所以把另一个工程的1.5.6改成1.5.8就可以了
4.到这一步，主要解决了这么几个问题：
4.1：跟踪功能可以配置，可以通过spring.sleuth.enabled=true来开启，不开的话默认就是false关闭的(原本默认是true开启的，通过实现EnvironmentPostProcessor接口来修改默认配置实现)
4.2：不配置kafka地址，工程也可以启动(原本不配置就会启动失败，通过反射跳过了抛出异常的那段代码)
4.3：如果开启了跟踪功能(spring.sleuth.enabled=true)的情况下，kafka地址没有配置，或者配置错的，或者kafka地址对的但是kafka挂了(总之kafak不可达)，那么会打印一次告警日志，但不会循环打印，这个完全可以接受，不影响程序运行(提高springboot版本到1.5.8)
5.梳理下面几个应用场景
5.1：不开启跟踪功能：比如客户规模小，没有这个必要，那么什么都不配置即可，4.2可保证程序可以正常启动，4.1可以保证程序不尝试发送跟踪信息(spring.sleuth.enabled被默认置为false了) ；
5.2：开启跟踪功能：配置spring.sleuth.enabled为true，配置正确的kafka地址即可；
5.3：开启了跟踪功能，但是kfka异常了：此时可以保证程序正常运行，只是多打印了error日志，通过日志告警来修复kafka，当然这就是另一个问题了；
5.4： 结合4和5，就可以保证client可以正常切换跟踪功能的开启和关闭，并且不需要修改代码和pom来实现了，只要修改配置即可。