SpringCloud - Spring Cloud Sleuth（1） - 简介

最新推荐文章于 2024-10-10 09:45:00 发布

mytt_10566

最新推荐文章于 2024-10-10 09:45:00 发布

阅读量784

点赞数

分类专栏： springcloud 文章标签： springcloud sleuth

springcloud 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

参考：https://cloud.spring.io/spring-cloud-static/Edgware.SR5/multi/multi__introduction.html

Spring Cloud Sleuth为Spring Cloud实现了分布式跟踪解决方案。

1. 术语
Spring Cloud Sleuth借用了Dapper的术语。

Span：基本工作单元。例如，发送RPC是一个新的span，就像向RPC发送响应一样。spans由一个唯一64位ID（span）和另一个64位ID（trace，span为其一部分）来标识。 Spans还有其他数据，例如描述、带时间戳的事件，键值注解（标签），导致它们的span的ID以及进程ID（通常是IP地址）。

Spans启动和停止，他们跟踪他们的时间信息。创建span后，必须在将来的某个时刻停止它。

提示：启动跟踪的初始范围称为root span。该span的span id值等于trace id。

Trace：一组span形成树状结构。例如，如果正在运行分布式大数据存储，则可能会由put请求形成跟踪。

Annotation：用于及时记录事件的存在。用于定义请求的开始和停止的一些核心注解是：

cs：Client Sent - 客户端已发出请求。此注解描述了span的开始。
sr：Server Received - 服务器端获得请求并将开始处理它。如果从该时间戳中减去cs时间戳，则会收到网络延迟。
ss：Server Sent - 在请求处理完成时注解（当响应被发送回客户端时）。如果从该时间戳中减去sr时间戳，则将接收服务器端处理请求所需的时间。
cr：Client Received - 表示span结束。客户端已成功收到服务器端的响应。如果从该时间戳中减去cs时间戳，则将接收客户端从服务器接收响应所需的全部时间。

使用Zipkin注解可视化Span和Trace在系统中的变化：

注解的每种颜色表示跨度（7个跨度 - 从A到G）。如果在说明中有此类信息：

Trace Id = X
Span Id = D
Client Sent

这意味着当前跨度的Trace-Id设置为X，Span-Id设置为D.它还发出了Client Sent事件。

span的父/子关系可能情况的可视化图如下所示：

2. 目的
在以下部分中，将思考上图中的示例。

2.1 使用Zipkin进行分布式跟踪
总共有7个span。如果你去查看Zipkin的跟踪记录，你会在第二个跟踪中看到这个数字：

但是，如果选择特定的跟踪，那么将看到4个span：

注：选择特定跟踪时，将看到合并的span。这意味着，如果通过Server Received和Server Sent / Client Received以及Client Sent 注解向Zipkin发送了2个span，那么它们将显示为单个span。

在这种情况下，为什么7和4个span之间存在差异？

2个span来自http:/start span。它具有服务器接收（SR）和服务器发送（SS）注解。
2个span来自从service1到service2的RPC调用到http:/foo端点。它在service1端具有客户端发送（CS）和客户端接收（CR）注解。它还在service2端具有服务器接收（SR）和服务器发送（SS）注解。物理上有2个span，但它们形成与RPC调用相关的1个逻辑span。
从Service2到service3到http:/bar端点的RPC调用有2个span。它在service2端具有客户端发送（CS）和客户端接收（CR）注解。它还在service3端具有服务器接收（SR）和服务器发送（SS）注释。物理上有2个span，但它们形成与RPC调用相关的1个逻辑span。
2个span来自从service2到service4的RPC调用到http:/baz端点。它在service2端具有客户端发送（CS）和客户端接收（CR）注解。它还在service4端具有服务器接收（SR）和服务器发送（SS）注解。物理上有2个span，但它们形成与RPC调用相关的1个逻辑span。

因此，如果我们计算物理span，我们从http:/start得到1，从service1调用service2得到2，service2调用service3的到2，从service2调用service4得到2。总共7个span。

从逻辑上讲，我们看到 Total Spans: 4 的信息，因为我们有1个与service1的传入请求相关的span和3个与RPC调用相关的span。

2.2 可视化错误
Zipkin允许可视化跟踪中的错误。当抛出一个异常并且没有被捕获时，我们就在Zipkin可以正确着色的span上设置适当的标签。可以在跟踪列表中看到一条红色的迹线，那是因为抛出了异常。

如果单击该跟踪，则会看到类似的图片：

然后，如果单击其中一个span，将看到以下内容

如图所示，可以轻松查看错误的原因以及与之相关的整个堆栈跟踪。

2.3 实例

Zipkin中的依赖关系图如下所示：

2.4 日志关联
trace id为2485ec27856c56f4，对这四个应用程序的日志进行聚合时将获得以下内容：

service1.log:2016-02-26 11:15:47.561  INFO [service1,2485ec27856c56f4,2485ec27856c56f4,true] 68058 --- [nio-8081-exec-1] i.s.c.sleuth.docs.service1.Application   : Hello from service1. Calling service2
service2.log:2016-02-26 11:15:47.710  INFO [service2,2485ec27856c56f4,9aa10ee6fbde75fa,true] 68059 --- [nio-8082-exec-1] i.s.c.sleuth.docs.service2.Application   : Hello from service2. Calling service3 and then service4
service3.log:2016-02-26 11:15:47.895  INFO [service3,2485ec27856c56f4,1210be13194bfe5,true] 68060 --- [nio-8083-exec-1] i.s.c.sleuth.docs.service3.Application   : Hello from service3
service2.log:2016-02-26 11:15:47.924  INFO [service2,2485ec27856c56f4,9aa10ee6fbde75fa,true] 68059 --- [nio-8082-exec-1] i.s.c.sleuth.docs.service2.Application   : Got response from service3 [Hello from service3]
service4.log:2016-02-26 11:15:48.134  INFO [service4,2485ec27856c56f4,1b1845262ffba49d,true] 68061 --- [nio-8084-exec-1] i.s.c.sleuth.docs.service4.Application   : Hello from service4
service2.log:2016-02-26 11:15:48.156  INFO [service2,2485ec27856c56f4,9aa10ee6fbde75fa,true] 68059 --- [nio-8082-exec-1] i.s.c.sleuth.docs.service2.Application   : Got response from service4 [Hello from service4]
service1.log:2016-02-26 11:15:48.182  INFO [service1,2485ec27856c56f4,2485ec27856c56f4,true] 68058 --- [nio-8081-exec-1] i.s.c.sleuth.docs.service1.Application   : Got response from service2 [Hello from service2, response from service3 [Hello from service3] and from service4 [Hello from service4]]

如果使用的是日志聚合工具，如Kibana、Splunk等，可以给发生的事件排序。 Kibana的一个例子如下所示：

如果你想使用Logstash，这里是Logstash的Grok模式：

filter {
       # pattern matching logback pattern
       grok {
              match => { "message" => "%{TIMESTAMP_ISO8601:timestamp}\s+%{LOGLEVEL:severity}\s+\[%{DATA:service},%{DATA:trace},%{DATA:span},%{DATA:exportable}\]\s+%{DATA:pid}\s+---\s+\[%{DATA:thread}\]\s+%{DATA:class}\s+:\s+%{GREEDYDATA:rest}" }
       }
}

如果要将Grok与Cloud Foundry中的日志一起使用，则必须使用以下模式：

filter {
       # pattern matching logback pattern
       grok {
              match => { "message" => "(?m)OUT\s+%{TIMESTAMP_ISO8601:timestamp}\s+%{LOGLEVEL:severity}\s+\[%{DATA:service},%{DATA:trace},%{DATA:span},%{DATA:exportable}\]\s+%{DATA:pid}\s+---\s+\[%{DATA:thread}\]\s+%{DATA:class}\s+:\s+%{GREEDYDATA:rest}" }
       }
}

使用Logstash的JSON Logback
通常，不希望将日志存储在文本文件中，而是存储在Logstash可以立即选择的JSON文件中。为此，必须执行以下操作（为了便于阅读，我们以 groupId:artifactId:version 格式表示依赖项）。

（1）依赖关系设置

确保Logback位于类路径上（ch.qos.logback:logback-core）
添加Logstash Logback - 4.6版本示例：net.logstash.logback:logstash-logback-encoder:4.6

（2）Logback设置

将来自应用程序的信息以JSON格式记录到build/$ {spring.application.name}.json文件中
已注释掉两个额外的appender - 控制台和标准日志文件
具有与上一节中介绍的相同的日志记录模式

示例：

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
	<include resource="org/springframework/boot/logging/logback/defaults.xml"/>
	
	<springProperty scope="context" name="springAppName" source="spring.application.name"/>
	<!-- Example for logging into the build folder of your project -->
	<property name="LOG_FILE" value="${BUILD_FOLDER:-build}/${springAppName}"/>

	<!-- 可以覆盖下面的配置，使用自定义的配置 -->
	<property name="CONSOLE_LOG_PATTERN"
			  value="%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}"/>

	<!-- 控制台日志 -->
	<appender name="console" class="ch.qos.logback.core.ConsoleAppender">
		<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
			<!-- 控制条展示的最小日志级别-->
			<level>DEBUG</level>
		</filter>
		<encoder>
			<pattern>${CONSOLE_LOG_PATTERN}</pattern>
			<charset>utf8</charset>
		</encoder>
	</appender>

	<!-- 文件日志 -->
	<appender name="flatfile" class="ch.qos.logback.core.rolling.RollingFileAppender">
		<file>${LOG_FILE}</file>
		<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
			<fileNamePattern>${LOG_FILE}.%d{yyyy-MM-dd}.gz</fileNamePattern>
			<maxHistory>7</maxHistory>
		</rollingPolicy>
		<encoder>
			<pattern>${CONSOLE_LOG_PATTERN}</pattern>
			<charset>utf8</charset>
		</encoder>
	</appender>
	
	<!-- 以JSON格式添加至日志文件 -->
	<appender name="logstash" class="ch.qos.logback.core.rolling.RollingFileAppender">
		<file>${LOG_FILE}.json</file>
		<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
			<fileNamePattern>${LOG_FILE}.json.%d{yyyy-MM-dd}.gz</fileNamePattern>
			<maxHistory>7</maxHistory>
		</rollingPolicy>
		<encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
			<providers>
				<timestamp>
					<timeZone>UTC</timeZone>
				</timestamp>
				<pattern>
					<pattern>
						{
						"severity": "%level",
						"service": "${springAppName:-}",
						"trace": "%X{X-B3-TraceId:-}",
						"span": "%X{X-B3-SpanId:-}",
						"parent": "%X{X-B3-ParentSpanId:-}",
						"exportable": "%X{X-Span-Export:-}",
						"pid": "${PID:-}",
						"thread": "%thread",
						"class": "%logger{40}",
						"rest": "%message"
						}
					</pattern>
				</pattern>
			</providers>
		</encoder>
	</appender>
	
	<root level="INFO">
		<appender-ref ref="console"/>
		<!-- uncomment this to have also JSON logs -->
		<!--<appender-ref ref="logstash"/>-->
		<!--<appender-ref ref="flatfile"/>-->
	</root>
</configuration>

注：如果使用的是自定义logback-spring.xml，则必须在bootstrap中传递 spring.application.name 而不是 application属性文件。否则，自定义logback文件将无法正确读取该属性。

2.5 传播span上下文
span上下文是必须传播到跨进程边界的任何子span的状态。span上下文的一部分是Baggage。trace和span ID是span上下文的必需部分。Baggage是可选部分。

Baggage是存储在span上下文中的一组键值对。Baggage与trace一起移动并附在每个span上。如果HTTP报头以 baggage- 为前缀，Spring Cloud Sleuth将理解报头是Baggage相关的，并且对于消息，它以 baggage_ 开头。

注：目前对baggage的数量或大小没有限制。但是，太多可能会降低系统吞吐量或增加RPC延迟。在极端情况下，由于超出传输级别的消息或报头容量，它可能会导致应用程序崩溃。

在span上设置baggage的示例：

Span initialSpan = this.tracer.createSpan("span");
initialSpan.setBaggageItem("foo", "bar");
initialSpan.setBaggageItem("UPPER_CASE", "someValue");

Baggage与span标签

Baggage和trace一起移动（即每个子span包含其父span的baggage）。 Zipkin不了解baggage，甚至不会收到这些信息。
标签附加到特定的span --- 它们仅针对特定span呈现。但是，可以按标记搜索以查找trace，其中存在具有搜索标记值的span。

如果希望能够根据baggage查找span，则应在root span中添加相应的条目作为标记。

@Autowired Tracer tracer;

Span span = tracer.getCurrentSpan();
String baggageKey = "key";
String baggageValue = "foo";
span.setBaggageItem(baggageKey, baggageValue);
tracer.addTag(baggageKey, baggageValue);

3. 集成到项目中
注：要确保在Zipkin中正确显示应用程序名称，在bootstrap.yml中设置spring.application.name属性。

3.1只有Sleuth（日志相关）
如果想在没有Zipkin集成的情况下仅从Spring Cloud Sleuth获取，只需将spring-cloud-starter-sleuth模块添加到项目中。

<dependencyManagement> 1
         <dependencies>
             <dependency>
                 <groupId>org.springframework.cloud</groupId>
                 <artifactId>spring-cloud-dependencies</artifactId>
                 <version>${release.train.version}</version>
                 <type>pom</type>
                 <scope>import</scope>
             </dependency>
         </dependencies>
   </dependencyManagement>

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

3.2 通过HTTP使用集成了Zipkin的Sleuth
如果想要Sleuth和Zipkin，只需添加spring-cloud-starter-zipkin依赖项。

<dependencyManagement> 1
         <dependencies>
             <dependency>
                 <groupId>org.springframework.cloud</groupId>
                 <artifactId>spring-cloud-dependencies</artifactId>
                 <version>${release.train.version}</version>
                 <type>pom</type>
                 <scope>import</scope>
             </dependency>
         </dependencies>
   </dependencyManagement>

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

3.3 通过RabbitMQ或Kafka使用集成了Zipkin的Sleuth
如果想使用RabbitMQ或Kafka而不是http，添加spring-rabbit或spring-kafka依赖项。默认目标名称是 zipkin。

注意：spring-cloud-sleuth-stream已经废弃了，并且与这些目标不兼容。

如果想要在RabbitMQ上使用Sleuth，添加spring-cloud-starter-zipkin和spring-rabbit依赖项。

<dependencyManagement> 1
         <dependencies>
             <dependency>
                 <groupId>org.springframework.cloud</groupId>
                 <artifactId>spring-cloud-dependencies</artifactId>
                 <version>${release.train.version}</version>
                 <type>pom</type>
                 <scope>import</scope>
             </dependency>
         </dependencies>
   </dependencyManagement>

   <dependency> 2
       <groupId>org.springframework.cloud</groupId>
       <artifactId>spring-cloud-starter-zipkin</artifactId>
   </dependency>
   <dependency> 3
       <groupId>org.springframework.amqp</groupId>
       <artifactId>spring-rabbit</artifactId>
   </dependency>