zipkin:mysql做存储,kafka做接收器,以及如何找到配置名称

mysql设定
  1. 创建表结构:
(源码路径)zipkin-storagemysqlsrcmain esourcesmysql.sql
  2. zipkin的存储设置为mysql(collector设置为kafka)
java -server -jar zipkin-server-2.6.1-exec.jar --zipkin.storage.type=mysql --zipkin.storage.mysql.host=10.4.122.89 --zipkin.storage.mysql.port=4001 --zipkin.storage.mysql.username=eop --zipkin.storage.mysql.password=eop123 --zipkin.storage.mysql.db=eop --zipkin.collector.kafka.zookeeper=10.4.120.77:2181
在配置的时候注意其实有两套report的FactoryBean(都在zipkin-reporter-springs-beans.jar下面),一套是report级别的(AsyncReporterFactoryBean),一套是report下面sender级别的senderFactoryBean(KafkaSenderFactoryBean,OkHttpSenderFactoryBean,RabbitMQSenderFactoryBean,URLConnectionSenderFactoryBean);对于kafka需要使用的是KafkaSenderFactoryBean;
kafka
之前碰到一个奇怪的问题,就是客户端就是调不通了,后来我写了一段java代码模拟producer,打出详细日志,才发现原来是因为kafka client端访问zookeeper,获取的是机器名称,但是我本地没有配置这个名称的ip映射导致;这个其实和之前的hbase的异常是一样;凡是通过zookeeper来获取机器的场景都要小心,本地一定要配置DNS。
 
kafka调通了,但是发现zipkin没有接收到日志信息;怎么回事?后来通过阅读源码“${zipkin-master}zipkin-autoconfigurecollector-kafkasrcmainjavazipkinautoconfigurecollectorkafka下面的三个类,知道配置的参数应该是zipkin.collector.kafka.zookeeper;修改参数名称之后,成功接收。
其实类似的对于各种collector以及storage获取其配置参数就看源码即可,XXCollectorProperties,@ConfigurationProperties(“XX”)里面的XX就是前缀,字段就是要填充到XX.fileldName的;比如kafka中:
@ConfigurationProperties("zipkin.collector.kafka")
class ZipkinKafkaCollectorProperties {
private String topic = "zipkin";
private String zookeeper;
private String groupId = "zipkin";
... ...
}
那么可以获知他的参数列表为zipkin.collector.kafka.zookeeper,zipkin.collector.kafka.topic,zipkin.collector.kafka.groupId等等。
 
zipkin日志异常分析
 
发现全是springcloudapp的名称,然后是springcloudapp(http://localhost:8080/hello/tom)工程单独调用并没有通知zipkin;
原来是因为restTemplate的获取,好用的是使用restTemplate的@autowire的方式,但是如果使用@autowired导致的异常:
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'appServer': Unsatisfied dependency expressed through field 'restTemplate': No qualifying bean of type [org.springframework.web.client.RestTemplate] found for dependency [org.springframework.web.client.RestTemplate]: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [org.springframework.web.client.RestTemplate] found for dependency [org.springframework.web.client.RestTemplate]: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}
 
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [org.springframework.web.client.RestTemplate] found for dependency [org.springframework.web.client.RestTemplate]: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}
原因就是这个@Autowired声明必须要有bean定义,但是当前的工程极简,根本没有spring的配置文件来配置这个字段,但是可以采用“监守自盗”的方式,就是在一个类中声明既声明了bean,也声明了@autowired;为什么要做这么做?因为@autowired声明后,spring将会管理这个对象的生命周期,就可以在这个对象创建的前后放入钩子(拦截器)对其进行处理,比如zipkin就是通过spring拦截了restTemplate的创建,使其可以拦截restTemplate的invokeUrl方法,实现日志收集。
1 @Autowired
2   RestTemplate restTemplate;
3  
4   @Bean
5   public RestTemplate getRestTemplate() {
6   return new RestTemplate();
7   }
后来又碰到了一个问题,就是gateway异常;后来才发现因为appServer的eureka没有配置(调试上面问题的时候,从别的好用的程序拷贝过来application.properites,内容直接干掉了,好用的那段配置没有配eureka);后来添加上了问题解决;但是我发现一旦这种情况发生,zuul竟然就崩溃了,再也无法提供服务?
 
dubbo的web工程没有反应了?
因为没有配置Spring,需要在WEB-INF下面添加一些spring相关的位置xml;
 
为什么调不通spring-app?
没加@RestController,所以mapping没有创建,这一点从日志可以看到,没有mapping /cloud/{name};
 
网关有挂了,http://localhost:8083/app/cloud/Jim 怎么跳转不过去了?
后来重启一次好了;zuul只有遇到了一些跳转的异常,就挂在那个地方了,及时后面正常请求也无法处理。
 
zuul为什么报错?
因为portal采用的是post方式提交请求;app的方法使用@GetMapping声明的,所以zuul通过post去访问app,超时结束。改为app的方法改为RequestMapping(接收任何http方法)问题解决。
 
方法还是很重要,我在A工程测试访问B工程可以形成一条链,我在C工程写法和A类似,访问E工程,无法形成一条链;于是开始搞C怎么和E没有反应呢?没有头绪,无法确定到底是C问题还还是E问题?
后来修改方案,直接让A工程调用E工程,OK,形成链!说明是C工程问题;
继续A采用的是spring+注入httpClient,B采用的spring + 静态方法httpClient(客户的遗留代码不是spring,这里主要是测试非注入方式是否可用,利用spriing只不过是为了快速搭建Web工程)。开始是主攻为什么静态的就不行呢?后来调整方案,先让B和A采用相同的结构,先保证A→E形成一条链,再根据spring的原理来改造B工程,这样始终都是基于成功的demo进行修改,保证开发的方向。
原文地址:https://www.cnblogs.com/xiashiwendao/p/8834839.html