Sleuth没有将跟踪信息发送给Zipkin,尽管Zipkin运行良好。我使用的是spring 1.5.8.Release,spring cloud Dalston.sr4和我在我的微服务中添加了以下依赖项:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
我的日志总是出现错误:[FOOMS,2E740F33C26E286D,2E740F33C26E286D,false]
我的Zipkin依赖项是:
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-server</artifactId>
</dependency>
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-autoconfigure-ui</artifactId>
<scope>runtime</scope>
</dependency>
为什么我的口供是假的而不是真的?但是,所有调用都正确生成了traceId和SpanId。我的Zipkin正在9411端口运行
如果您要将所有的span数据导出到Zipkin,那么可以通过在spring boot main类中创建一个bean定义来安装sampler
@Bean
public Sampler defaultSampler() {
return new AlwaysSampler();
}
对于最新版本的云依赖关系
向zipkin发送跟踪的正确属性是:spring.sleuth.sampler.probability=1.0
,它已从百分比更改为概率。
我发现我需要添加一个采样器百分比。默认情况下,发送的样本百分比为零,这就是为什么sleuth没有发送任何东西给Zipkin的原因。当我在属性文件中添加spring.sleuth.sampler.percentage=1.0
时,它开始工作。
我正在尝试将sleuth集成到Spring Boot应用程序中,这样它就可以与zipkin服务器进行跟踪,但我的运气不太好。我已经学习了一些教程(链接到tutorial),让他们与zipkin对话没有问题,但是它不能很好地转换到我的应用程序中,我不确定该去哪里找。 基本上,在build.gradle文件的依赖项部分,我添加了: 并且,我将这些内容添加到application.properties文
从现有检测的Spring Boot应用程序向honeycomb-opentracing-proxy发送跟踪失败,代理控制台中出现以下错误: Spring Boot版本:2.1.3.发布Spring Cloud Sleuth版本:2.1.1.发布 应用程序.属性 如有任何帮助,我将不胜感激
我最近将我的项目从spring boot 1.4.1、spring cloud Sleuth 1.1.0、spring cloud Zipkin 1.1.0升级到spring boot 1.5.3、spring cloud Sleuth 1.2.0、spring cloud Zipkin 1.2.0。 在最新版本的spring cloud Sleuth中,他们添加了“错误”标签,一旦出现任何异常,
更新:我已将代码推送到我的回购协议中,以便人们可以查看那里,看看可能出现了什么问题。 编辑:我几乎可以肯定是客户端代码没有向服务器发布任何统计数据,但是下面的指南都没有解释如何启用:是否有我缺少的配置设置? 我一直在关注OpenZipkin和Spring Sleuth的快速启动:我从docker Zipkin使用和Cassandra作为后端运行Zipkin服务器: 我已经创建并运行了Spring
我将使用Zipkin在现有代码中添加Spring Cloud Sleuth,以收集跟踪信息,并最终记录任意消息。正常的请求跨度被正确地发送到Zipkin: 检查Zipkin中的跟踪,可以正确地找到span,但是却看不到行中使用的消息--这表明我在这里做了一些错误的事情,或者它不应该以这种方式工作。我的抽样百分比设置为100%。 使用slf4j接口会很方便,因为现有的代码已经以这种方式检测了。有可能
Zipkin跟踪演示使用Zipkin作为跟踪服务端,提供跟踪Envoy请求记录展示的功能。这个沙箱与上面描述的前端代理架构非常类似,但有一点不同:在响应返回之前,service1对service2进行API调用。这三个容器将被部署在名为envoymesh的虚拟网络中。 所有的请求都经过前端Envoy进行路由,该Envoy充当位于envoymesh网络边缘的反向代理。端口80通过docker com