整合Sleuth

Sleuth是 springcloud 分布式跟踪解决方案。

Sleuth 术语:

跨度(span ) :Sleuth 的基本工作单元,他用一个64位的id唯一标识。出ID外,span还包含 其他的数据,如 描述,时间戳事件,键值对注解等,spanid span父ID等。

trace 跟踪:一组span组成的树状结构称为 trace。

annotation 标注:

cs 客户端发送

SR 服务端接收

SS 服务端发送

CR 客户端接收

整合Sleuth:

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-sleuth</artifactId>
        </dependency>

这就整合好了sleuth.

整合ZIPKIN

zipkin 的作用是 Twitter 开源分布式跟踪系统,主要用来收集系统的时序数据,从而跟踪系统的调用问题。

zip的下载与搭建

http://www.imooc.com/article/291572

增加 pom.xml

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zipkin</artifactId>
        </dependency>

这时候可以去掉 前面的 Sleuth依赖,应为这个已经包含了 sleuth 的依赖。

修改 application.properties 增加配置:

# 调用链配置。
spring.zipkin.base-url=http://localhost:9411/
spring.zipkin.discoveryClientEnabled=false
spring.sleuth.sampler.probability=1

1.zipkin服务器地址

2.采样率 这里设置为1,在生产环境中这个 需要设置低一些,比如为0.1 就是十次采样一次。

测试访问一次服务后,查看zipkin。

通过调用链 可以分析调用的问题。

如果调用出现红色,那么这个表示出错,就需要分析原因了。

整合 zipkin nacos 报错解决

http://www.imooc.com/article/291578

原文地址:https://www.cnblogs.com/yg_zhang/p/12639998.html

时间: 2024-08-30 18:25:00

整合Sleuth的相关文章

SpringCloud之链路追踪整合Sleuth(十三)

前言 SpringCloud 是微服务中的翘楚,最佳的落地方案. 在一个完整的微服务架构项目中,服务之间的调用是很复杂的,当其中某一个服务出现了问题或者访问超时,很 难直接确定是由哪个服务引起的,所以就有了 Spring Cloud Sleuth 链路跟踪.通过它,我们就可以很清楚直观 的了解每一个服务请求经过了哪些服务,用时多久,谁依赖谁或者被谁依赖. 代码 product-service       <dependency> <groupId>org.springframewo

SpringCloud整合sleuth,使用zipkin时不显示服务

刚开始以为是版本不兼容,后来发现是因为配置没对,需要加 sender: type: web yaml格式如下: spring:application:name: xxxzipkin:base-url: http://localhost:9411/sender:type: web sleuth:sampler:probability: 1 转载于:https://www.cnblogs.com/Dandwj/p/11179141.html 原文地址:https://blog.csdn.net/we

spring cloud 入门系列八:使用spring cloud sleuth整合zipkin进行服务链路追踪

好久没有写博客了,主要是最近有些忙,今天忙里偷闲来一篇. =======我是华丽的分割线========== 微服务架构是一种分布式架构,微服务系统按照业务划分服务单元,一个微服务往往会有很多个服务单元,一个请求往往会有很多个单元参与,一旦请求出现异常,想要去定位问题点真心不容易,因此需要有个东西去跟踪请求链路,记录一个请求都调用了哪些服务单元,调用顺序是怎么样的以及在各个服务单元处理的时间长短.常见的服务链路追踪组件有google的dapper.twitter的zipkin.阿里的鹰眼等,它们

新版本SpringCloud sleuth整合zipkin

SpringCloud Sleuth 简介 Spring Cloud Sleuth为Spring Cloud实现了分布式跟踪解决方案. Spring Cloud Sleuth借鉴了Dapper的术语. Span:基本的工作单元.Span包括一个64位的唯一ID,一个64位trace码,描述信息,时间戳事件,key-value 注解(tags),span处理者的ID(通常为IP). Trace:一组Span形成的树形结构. Annotation:用于及时记录存在的事件.常用的Annotation如

springcloud -- sleuth+zipkin整合rabbitMQ详解

为什么使用RabbitMQ? 我们已经知道,zipkin的原理是服务之间的调用关系会通过HTTP方式上报到zipkin-server端,然后我们再通过zipkin-ui去调用查看追踪服务之间的调用链路.但是这种方式存在一个隐患,如果微服务之间与zipkin服务端网络不通,或调用链路上的网络闪断,http通信收集方式就无法工作.而且zipkin默认是将数据存储在内存中的,如果服务端重启或宕机,就会导致数据丢失. 所以我们不仅将数据存储在zipkin-serve中,同时还能通过某个消息存储的容器将本

Spring Cloud(十二):分布式链路跟踪 Sleuth 与 Zipkin【Finchley 版】

Spring Cloud(十二):分布式链路跟踪 Sleuth 与 Zipkin[Finchley 版] 发表于 2018-04-24 | 随着业务发展,系统拆分导致系统调用链路愈发复杂一个前端请求可能最终需要调用很多次后端服务才能完成,当整个请求变慢或不可用时,我们是无法得知该请求是由某个或某些后端服务引起的,这时就需要解决如何快读定位服务故障点,以对症下药.于是就有了分布式系统调用跟踪的诞生. 现今业界分布式服务跟踪的理论基础主要来自于 Google 的一篇论文<Dapper, a Larg

SpringCloud实战-Sleuth

Spring-Cloud-Sleuth是Spring Cloud的组成部分之一,为SpringCloud应用实现了一种分布式追踪解决方案,其兼容了Zipkin, HTrace和log-based追踪,追踪微服务rest服务调用链路的问题,接触到zipkin,而spring cloud也提供了spring-cloud-sleuth来方便集成zipkin实现. 为什么需要进行分布式链路追踪springcloud-sleuth呢? 随着分布式系统越来越复杂,你的一个请求发过发过去,各个微服务之间的跳转

十二、springcloud之展示追踪数据 Sleuth+zipkin

一.Zipkin简介 Zipkin是Twitter的一个开源项目,它基于Google Dapper实现.我们可以使用它来收集各个服务器上请求链路的跟踪数据,并通过它提供的REST API接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序,从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源.除了面向开发的API接口之外,它也提供了方便的UI组件来帮助我们直观的搜索跟踪信息和分析请求链路明细,比如:可以查询某段时间内各用户请求的处理时间等. 上图展示了Zipkin的基础架构,它主要有

Spring 5.x 、Spring Boot 2.x 、Spring Cloud 与常用技术栈整合

本项目仓库提供spring.spring-boot.spring-cloud 的常用整合用例.每个用例都提供详细的图文说明,并给出官方文档的具体链接作为参考.随着spring的迭代,本仓库会持续更新,升级版本和丰富用例. 仓库地址:https://github.com/heibaiying/spring-samples-for-all 版本说明: Spring: 5.1.3.RELEASE Spring-Boot:2.1.1.RELEASE Spring-Cloud:Finchley.SR2 目