微服务监控之分布式链路追踪技术 Sleuth + Zipkin

微服务监控之分布式链路追踪技术 Sleuth + Zipkin

• 1. 分布式链路追踪技术适用场景
  
• 
  
  
  
  • 1.1 场景形貌
    
  • 1.2 分布式链路追踪技术
    
  • 1.3 市场上的分布式链路追踪方案
    
    
  
• 2. 分布式链路追踪技术核心思想
  
• 3. Sleuth + Zipkin
  
• 
  
  
  
  • 3.1 引入 Sleuth
    
  • 3.2 Zipkin Server 构建
    
  • 3.3 Zipkin Client 构建
    
  • 3.4 追踪数据 Zipkin 持久化到 MySql
    
  
  

1. 分布式链路追踪技术适用场景

1.1 场景形貌

为了支撑日益增长的巨大业务量，我们会使用微服务架构设计系统，使系统不但能够通过集群摆设抵抗流量的打击，又能根据业务进行灵活的扩展。
那么，在微服务架构下，一次请求少则颠末三四次服务调用完成，多则凌驾几十个甚至是上百个服务节点。那么问题接踵而来：

• 如何动态展示服务的调用链路？（好比：A服务调用了哪些其他的服务）
  
• 如何分析服务调用链路中的瓶颈节点并对其进行调优？(好比：A > B > C，C服务处置处罚时间特别长)
  
• 如何快速进行服务链路的故障发现？
  

  这就是分布式链路追踪技术存在的目的和意义

1.2 分布式链路追踪技术

如果在一个请求的调用处置处罚过程中，在各个链路节点都能够记载下日志，并最终将日志进行集中可视化展示，那么想监控调用链路中的一些指标就有希望了。好比，请求到达哪个服务实例？请求被处置处罚的状态怎样？处置处罚耗时怎样？这些都能够分析出来了…

  分布式情况下基于这种想法实现的监控技术就是就是分布式链路追踪（全链路追踪）。

1.3 市场上的分布式链路追踪方案

分布式链路追踪技术已然成熟，产物也不少，国表里都有，好比

• Spring Cloud Sleuth + Twitter Zipkin
  
• 阿里巴巴的 “鹰眼”
  
• 大众点评的 “CAT”
  
• 美团的 “Mtrace”
  
• 京东的 “Hydra”
  
• 新浪的 “Watchman”
  

别的尚有最近也被提到许多的 Apache Skywalking。
2. 分布式链路追踪技术核心思想

本质：记载日志，作为一个完整的技术，分布式链路追踪也有自己的理论和概念微服务架构中，针对请求处置处罚的调用链可以展现为一棵树，示意如下：

上图形貌了一个常见的调用场景，一个请求通过网关服务路由到下游的 微服务-1，然后微服务-1调用微服务-2，拿到效果后再调用微服务-3，最后组合微服务-2和微服务-3的效果，通过网关返回给用户
为了追踪整个调用链路，肯定需要记载日志，日志记载是底子，在此之上肯定有一些理论概念，当下主流的的分布式链路追踪技术/系统所基于的理念都来自于Google的一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，我们来看下，这里面涉及到的核心理念是什么

上图表示一条请求链路，一条链路 通过 TraceId 唯一标识，通过 Span 表示发起的请求信息，各 Span 通过 parrentId 关联起来
Trace：服务追踪的追踪单元是从客户发起请求（request）抵达被追踪系统的界限开始，到被追踪系统向客户返回响应（response）为止的过程
Trace ID：为了实现请求跟踪，当请求发送到分布式系统的入口端点时，只需要服务跟踪框架为该请求创建一个唯一的跟踪标识 Trace ID，同时在分布式系统内部流转的时候，框架始终保持该唯一标识，直到返回给请求方

  一 个 Trace 由一个大概多个 Span 组成，每一个 Span 都有一个 SpanId，Span 中会记载 TraceId，同时尚有一个叫做 ParentId，指向了别的一个 Span 的 SpanId，表明父子关系，实在本质表达了依赖关系

Span ID：为了统计各处置处罚单元的时间延迟，当请求到达各个服务组件时，也是通过一个唯一标识 Span ID 来标志它的开始，具体过程以及竣事。对每一个 Span 来说，它必须有开始和竣事两个节点，通过记载开始 Span 和竣事 Span 的时间戳，就能统计出该 Span 的时间延迟，除了时间戳记载之外，它还可以包含一些其他元数据，好比时间名称、请求信息等。

  每一个 Span 都会有一个唯一跟踪标识 Span ID，若干个有序的 Span 就组成了一个 Trace。

Span 可以认为是一个日志数据布局，在一些特殊的时机点会记载了一些日志信息，好比有时间戳、SpanId、TraceId，parentId等，Span 中也抽象出了别的一个概念，叫做事件，核心事件如下：

• CS ：client send/start 客户端/消费者发出一个请求，形貌的是一个Span开始
  
• SR: server received/start 服务端/生产者吸收请求 SR-CS属于请求发送的网络延迟
  
• SS: server send/finish 服务端/生产者发送应答 SS-SR属于服务端消耗时间
  
• CR：client received/finished 客户端/消费者吸收应答 CR-SS表示复兴需要的时间(响应的网络延迟)
  

Spring Cloud Sleuth （追踪服务框架）可以追踪服务之间的调用，Sleuth 可以记载一个服务请求颠末哪些服务、服务处置处罚时长等，根据这些，我们能够理清各微服务间的调用关系及进行问题追踪分析。

• 耗时分析：通过 Sleuth 相识采样请求的耗时，分析服务性能问题（哪些服务调用比力耗时）
  
• 链路优化：发现频仍调用的服务，针对性优化等
  

  Sleuth 就是通过记载日志的方式来记载踪迹数据的

注意：我们往往把 Spring Cloud Sleuth 和 Zipkin 一起使用，把 Sleuth 的数据信息发送给 Zipkin 进行聚合，使用 Zipkin 存储并展示数据。

3. Sleuth + Zipkin

3.1 引入 Sleuth

• 每⼀个需要被追踪踪迹的微服务⼯程都引⼊依赖坐标
  

1.     org.springframework.cloud    spring-cloud-starter-sleuth

复制代码

• 每⼀个微服务都修改application.yml设置⽂件，添加⽇志级别
  

1. # 分布式链路追踪logging:  level:    org.springframework.web.servlet.DispatcherServlet: debug    org.springframework.cloud.sleuth: debug

复制代码

修改完成后，当请求到来时，在控制台可以观察到 Sleuth 输出的⽇志（全局TraceId、SpanId 等）。

这样的⽇志⾸先不容易阅读观察，别的⽇志分散在各个微服务服务器上，接下来我们使⽤Zipkin统⼀聚合轨迹⽇志并进⾏存储展示。

• 团结 Zipkin 展示追踪数据
  

  Zipkin 包罗 Zipkin Server 和 Zipkin Client 两部门，Zipkin Server 是⼀个单独的服务，Zipkin Client 就是具体的微服务

3.2 Zipkin Server 构建

• pom.xml
  

1.                                 io.zipkin.java                zipkin-server                2.12.3                                                                                                org.springframework.boot                                spring-boot-starter-log4j2                                                                                io.zipkin.java                zipkin-autoconfigure-ui                2.12.3       

复制代码

• 添参加口启动类
  

1. package com.study;import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import zipkin2.server.internal.EnableZipkinServer;/** * @author xiaosong * @version 1.0 * @since 2020/12/31 */@SpringBootApplication@EnableZipkinServer // 开启 Zipkin Server 功能public class ZipkinApplication9411 {    public static void main(String[] args) {        SpringApplication.run(ZipkinApplication9411.class,args);    }}

复制代码

• application.yml
  

1. server:  port: 9411  # 关闭自动检测请求management:  metrics:    web:      server:        auto-time-requests: false

复制代码

3.3 Zipkin Client 构建

  Zipkin Client 在具体微服务的项目中修改

• pom.xml 中添加 Zipkin 依赖
  

1.         org.springframework.cloud        spring-cloud-starter-zipkin

复制代码

• application.yml 中添加对 Zipkin Server 的引用
  

[code][/code]

  别的，log 日志依然保持开启 debug 状态

Zipkin Server ⻚⾯⽅便我们检察服务调⽤依赖关系及⼀些性能指标和异常信息
3.4 追踪数据 Zipkin 持久化到 MySql


来源：https://blog.csdn.net/HelloCedar/article/details/112001885
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！