"Microservices in Action" Chapter 32 Microservice Link Tracking - sleuth zipkin

Series Article Directory

Chapter 32 Microservice Link Tracking-sleuth zipkin
Chapter 30 Distributed Transaction Framework seata TCC Mode
Chapter 29 Distributed Transaction Framework seata AT Mode
Chapter 12 Spring Cloud Alibaba Sentinel
Chapter 11 Spring Cloud Alibaba nacos Configuration Center
Chapter 10 Spring Cloud Alibaba’s Nacos discovery
Chapter 7 Spring Cloud’s GateWay
Chapter 6 Spring Cloud’s OpenFeign

---

foreword

In a large-scale distributed microservice system, a system is split into N modules, which are responsible for different functions and combined into a system, which can finally provide rich functions. In this distributed architecture, a request often involves complex calls between multiple services, and the cost of maintenance is multiplied. There are bound to be the following problems:

• How can the dependency and dependent relationship between services be clearly seen?
• How to quickly locate the abnormal service when an exception occurs?
• How to quickly locate which service is affected when a performance bottleneck occurs?

In order to quickly locate problems in a distributed architecture, distributed link tracing came into being. Restore a distributed request into a call link, perform logging, performance monitoring, and centrally display the call status of a distributed request.

1、Spring Cloud Sleuth

A distributed service tracking system, mainly has three parts: data collection, data storage and data display.

The tracking unit of service tracking is the process from when the client initiates a request (request) to the boundary of the tracked system until the tracked system returns a response (response) to the client, which is called a "trace". Several services are called in each trace. In order to record which services are called and the time spent for each call, a call record is embedded every time a service is called, which is called a "span". In this way, several ordered spans form a trace. In the process of the system providing services to the outside world, requests and responses will continue to occur, and traces will be generated continuously. By recording these traces with spans, a service topology map of the system can be drawn. With the response time in the span and information such as whether the request is successful or not, you can find abnormal services when problems occur; based on historical data, you can also analyze where the performance is poor from the overall system level and locate the goal of performance optimization.

Spring Cloud Sleuth is only responsible for generating monitoring data, which is displayed in the form of logs, and does not provide a visual UI interface.

Spring Cloud Sleuth can combine zipkin to send information to zipkin, use zipkin storage to store information, and use zipkin ui to display data.

1.1. Concept

1.1.1、Span

The basic unit of work is equivalent to a node in the linked list, and its start, specific process and end are marked by a unique ID. We can count the time-consuming service calls through the start and end timestamps stored in it. In addition, you can also get the name of the event, request information, etc.

1.1.2、Trace

A series of Spans are connected in series to form a tree structure. When a request reaches the entrance of the system, a unique ID (traceId) will be created to uniquely identify a link. This traceId is always passed between services until the request is returned, then you can use this traceId to concatenate the entire request to form a complete link.

1.1.3、Annotation

Some core annotations are used to mark events between microservice calls, and the important ones are as follows:

• cs (Client Send): The client sends a request to start a request life cycle
• sr (Server Received): The server accepts the request and processes it; sr-cs = network delay
• ss (Server Send): The server is ready to send to the client after processing; ss - sr = request processing time on the server
• cr (Client Reveived): The client receives the response from the server, and the request ends; cr - sr = the total time of the request

2. spring cloud integrates sleuth

Prepare four servings

• business-service
• account-service
• storage-service
• order-service

2.1. Add dependencies in common-service

<!--链路跟踪-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

2.2. Add configuration in each business service

## 设置openFeign和sleuth的日志级别为debug，方便查看日志信息
logging:
  level:
    org.springframework.cloud.openfeign: debug
    org.springframework.cloud.sleuth: debug

• First: service name
• The second one: traceId, which uniquely identifies a link
• The third one: spanId, the basic work unit id in the link

3. Integrate zipkin

Zipkin is an open source project of Twitter, which is implemented based on Google Dapper, and it is dedicated to collecting timing data of the service.

Zipkin is divided into 4 core components, as follows:

• Collector: The collector component, which is mainly used to process the tracking information sent from the external system, and convert the information into the Span format internally processed by Zipkin to support subsequent storage, analysis, display and other functions.
• Storage: The storage component, which mainly processes the tracking information received by the collector. By default, this information is stored in memory. We can also modify this storage strategy to store tracking information in the database by using other storage components.
• RESTful API: API component, which is mainly used to provide external access interface. For example, display tracking information to the client, or connect to external system access for monitoring, etc.
• UI: The upper layer application implemented based on API components. Through the UI component, users can conveniently and intuitively query and analyze tracking information
  . Zipkin is divided into server and client. The server is mainly used to collect and display tracking data. The main function of the client is to send it to the server. The application of microservices is also the client. Once a call occurs, the listener will be triggered to transmit the sleuth log data to the server.

3.1. Build zipkin server

3.1.1. Download and install

Download: https://repo1.maven.org/maven2/io/zipkin/zipkin-server/2.24.0/zipkin-server-2.24.0-exec.jar
Put the java package in the zipkin on the d drive
Start: java -jar zipkin-server-2.24.0-exec.jar
Access the system: http://127.0.0.1:9411/

3.1.2. Add dependencies in common-service

<!--链路追踪 zipkin依赖，其中包含Sleuth的依赖-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
    <version>2.2.8.RELEASE</version>
</dependency>

3.1.3. Add configuration to each business service

spring:
  cloud:
    sleuth:
      sampler:
        # 日志数据采样百分比，默认0.1(10%)，这里为了测试设置成了100%，生产环境只需要0.1即可
        probability: 1.0
      zipkin:
        #zipkin server的请求地址
        base-url: http://127.0.0.1:9411
        #让nacos把它当成一个URL，而不要当做服务名
        discovery-client-enabled: false