链路追踪组件学习
1. 为啥需要链路追踪在分布式系统中，链路追踪是非常重要的工具，重要原因如下：
[*]解决微服务间的调用追踪题目
[*]在传统的单体应用中，全部的逻辑和请求都发生在一个进程内，系统的行为相对简单，题目的定位也相对直接。
[*]然而，随着系统架构变为分布式（尤其是微服务架构），请求通常会在多个服务间流转，这使得题目的定位变得更加困难。链路追踪可以资助开发者跟踪每个请求在各个微服务之间的传播，确保在分布式环境中也能全面了解请求的路径。
[*]进步故障定位和排查服从
[*]在分布式系统中，服务间的调用链条每每非常复杂，大概会涉及多个服务、数据库和其他资源。在出现题目时（如延迟、错误、服务不可用等），开发者很难知道题目发生在哪一层级。
[*]链路追踪通过记载请求从一个服务到另一个服务的全过程，包括服务的响应时间、调用关系、错误信息等，使得开发者可以快速定位到题目所在的具体服务和操作。
[*]性能瓶颈分析
[*]分布式系统中的请求通常跨多个服务和呆板，性能瓶颈大概出现在某个具体服务或接口上。链路追踪可以或许体现每个请求的时间分布，资助开发者找到响应时间长的服务，从而优化性能。
[*]通过链路追踪，可以清晰看到各个微服务之间的调用时间、排队时间以及响应时间，快速发现系统瓶颈。
[*]监控和可视化
[*]当代分布式系统需要连续的监控和分析。链路追踪不仅可以或许网络服务的调用数据，还可以或许将这些数据通过可视化工具（如 Zipkin、skyWalking 等）展示出来，资助开发者或运维职员更直观地了解系统的健康状况。
[*]通过图形化的方式查看服务之间的调用关系和依赖关系，有助于理解系统的架构，并发现潜在的题目和优化空间。
2. 常见的链路追踪组件
在举行链路追踪工具的选型时，需要考虑多个方面，以确保所选方案可以或许有效满足系统的需求。以下是一些关键考量因素：
维度Spring Cloud SleuthZipkinJaegerOpenTelemetryElastic APMPrometheus + GrafanaApache SkyWalkingDataDog APM技能栈兼容性高（Spring 系列）高（Java、Spring）高（多语言支持）高（多语言支持）高（多语言支持）中（重要为度量工具，链路追踪需要集成）高（多语言支持）高（多语言支持）功能特性自动化追踪，日记集成分布式追踪，存储查询分布式追踪，高性能监控跨语言支持，综合追踪性能监控，事务追踪度量监控，需配合链路追踪高（分布式追踪、APM）性能监控，事务追踪存储与查询本领依赖 Zipkin 存储支持内存和其他存储后端分布式存储，查询强大灵活，支持多种后端支持 Elastic StackPrometheus 存储，Grafana 可视化内建存储与查询功能高效存储与查询本领扩展性与可伸缩性较好（基于 Spring）良好（支持分布式）非常高（分布式、水平扩展）高（分布式支持，水平扩展）高（Elastic Stack 扩展）适合大规模数据网络与可视化高（支持大规模分布式监控）非常高（云原生支持）易用性和学习曲线简单，Spring 生态集成简单，配套工具丰富学习曲线较陡，复杂配置中等，跨语言学习曲线简单，Elastic Stack 认识度高需要联合配置使用，复杂度较高中等，较为复杂简单，界面友好社区和支持强大，Spring 生态强大，活跃社区强大，广泛应用开源，社区活跃强大，Elastic 社区强大，开源社区强大，社区活跃强大，付费支持成本免费（开源）免费（开源）免费（开源）免费（开源）商业化（Elastic 订阅费用）免费（开源）免费（开源）商业化（按需计费）安全性基于 Spring 安全集成可配置加密支持加密与认证支持加密与认证强（Elastic Stack 支持）可联合 Prometheus 加密配置支持加密和认证高（商业化方案提供安全性）集成本领与 Spring 生态集成与多种工具集成强（支持多种后端）强（与多种系统兼容）与 Elastic Stack 集成集成 Prometheus 等监控工具强（支持多种后端）强（与多种工具兼容）合规性与隐私需要自行管理需要自行管理支持隐私控制支持隐私控制支持（符合 GDPR 等）需要自行配置支持（符合 GDPR 等）高（提供合规工具） 结论：
[*]Spring Cloud Sleuth: 适合已经使用 Spring 生态的项目，简单易用，适合小到中型应用。
[*]Zipkin: 实用于需要独立的分布式链路追踪系统的场景，社区活跃。
[*]Jaeger: 高性能，实用于需要处理大规模数据的场景，支持水平扩展。
[*]OpenTelemetry: 跨语言支持强，实用于多种系统集成，适合对灵活性有高要求的项目。
[*]Elastic APM: 实用于已经在使用 Elastic Stack 的团队，集成轻便，提供及时监控。
[*]Prometheus + Grafana: 适合需要度量监控与可视化的系统，虽然重要用于监控，但可扩展到链路追踪。
[*]Apache SkyWalking: 开源且功能全面，实用于大规模分布式系统，支持多种语言和后端。
[*]DataDog APM: 商业化服务，提供全面的监控与分析，适合对支持与安全性有较高要求的企业级应用。
3. 使用过的链路追踪组件
根据您的需求（中型项目，基于 Spring Cloud 框架，且方向开源项目），我保举以下三种链路追踪框架：
3.1. Spring Cloud Sleuth
[*]技能栈兼容性: 作为 Spring 生态的一部分，Spring Cloud Sleuth 完美集成于 Spring Cloud 中，支持 Spring Boot 等项目，减少了手动配置的复杂度。
[*]功能特性: 支持自动化追踪，可以或许与日记框架（如 Logback、Log4j）集成，非常适合 Spring 系统。
[*]存储与查询本领: 依赖于 Zipkin 等后端举行数据存储和查询，支持多种存储选项，灵活配置。
[*]扩展性与可伸缩性: 基于 Spring Cloud，支持微服务架构的扩展和伸缩。
[*]易用性和学习曲线: 对 Spring 开发者非常友好，易于上手。
[*]成本: 开源免费，适合中型项目。
[*]集成本领: 与 Spring 生态系统集成紧密，适合使用 Spring Cloud 的项目。
3.2. Zipkin
[*]技能栈兼容性: 与多种技能栈兼容，尤其适合 Java 系统，Spring Cloud Sleuth 默认使用 Zipkin 存储链路追踪数据。
[*]功能特性: 提供分布式追踪，支持存储和查询链路信息，功能完善。
[*]存储与查询本领: 支持多种存储后端（如 Elasticsearch、MySQL 等），且查询功能强大。
[*]扩展性与可伸缩性: 适合分布式系统，支持水平扩展，能应对中型系统的需求。
[*]易用性和学习曲线: 易于部署和配置，但需要根据现实需求选择合适的存储后端。
[*]成本: 完全开源，适合预算有限的中型项目。
[*]集成本领: 与其他监控和日记系统（如 Prometheus、Elasticsearch）集成良好。
3.3. Apache SkyWalking
[*]技能栈兼容性: 支持多种技能栈，包括 Spring、Spring Boot，实用于多语言分布式环境。
[*]功能特性: 提供分布式追踪、性能监控和错误分析等功能，适合复杂应用的全面监控。
[*]存储与查询本领: 内建存储系统，提供高效的查询本领，适合中型及以上规模的系统。
[*]扩展性与可伸缩性: 具有很高的扩展性，支持大规模分布式系统。
[*]易用性和学习曲线: 配置相对复杂，但有丰富的文档支持。
[*]成本: 开源免费，适合预算有限的中型项目。
[*]集成本领: 支持与多种后端系统和监控工具集成，兼容性强。
4. 集成Spring Cloud Sleuth框架
Spring Cloud Sleuth 是一个分布式跟踪框架，旨在为微服务架构中的请求链提供追踪功能。它通过生成唯一的跟踪标识（Trace ID）和跨度标识（Span ID）来资助追踪跨服务的请求。集成 Spring Cloud Sleuth，可以有效地监控、分析和调试分布式系统中的请求流。
4.1. 流程步调
下面是怎样在 Spring Cloud 项目中集成 Spring Cloud Sleuth 的详细步调：
[*]添加依赖
首先，需要在 pom.xml 中添加 Spring Cloud Sleuth 依赖。如果你使用的是 Spring Boot 2.x 和 Spring Cloud Hoxton 或以上版本，可以通过以下方式引入 Sleuth：
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<!-- 如果使用Spring Cloud Stream或者其他相关模块，还需要添加Spring Cloud Sleuth支持的其他模块 -->
</dependencies>
[*]配置 Spring Cloud Sleuth
在 application.properties 或 application.yml 中，添加一些配置项来定制 Spring Cloud Sleuth 的行为。
#yaml
spring:
sleuth:
enabled: true
# trace-id 长度为16
trace-id-length: 16
sampler:
#链路追踪采样率
#采样率 1.0：表示每个请求都会被追踪。
#采样率 0.0：表示没有请求会被追踪。
#中间值：根据概率来决定是否追踪。
probability: 1.0
logging:
pattern:
level: "%5p [%X{X-B3-TraceId},%X{X-B3-SpanId}] %m%n"
[*]自动生成跟踪信息
Spring Cloud Sleuth 会自动在请求处理中为每个 HTTP 请求生成一个 TraceId 和 SpanId。这些 ID 会通报到下游服务，使得你可以追踪整个请求链。Sleuth 默认会将追踪信息注入到日记中（比方 MDC 中的 X-B3-TraceId 和 X-B3-SpanId）
Sleuth 通过为每个请求生成唯一的标识符来实现分布式追踪。它使用 TraceId 和 SpanId 来标识和追踪请求的生命周期。其核心概念包括：
https://i-blog.csdnimg.cn/direct/32bbdc4fe9f34eef951c16ed21d6baf7.png#pic_center
[*]TraceId：一个全局唯一的标识符，代表整个请求的生命周期。每个请求从入口服务到最终服务都有相同的 TraceId。
[*]SpanId：表示单个操作或请求的执行段，每个 Trace 会包罗多个 Span。每个服务中的每个处理请求的操作都会创建一个新的 Span，并与 TraceId 关联。
[*]Parent SpanId：表示当前 Span 的父 Span，如果一个请求是由另一个请求引发的，它会继承上一个请求的 SpanId 作为 Parent SpanId。
https://i-blog.csdnimg.cn/direct/c38de79c01ba40f9bf3feacc312d2732.png#pic_center
格式说明微服务ID指明日记是由哪个微服务产生的。TraceId轨迹编号。一次完备的业务处理过程被称为轨迹，比方：实现登录功能需要从服务 A 调用服务 B，
服务B再调用服务 C，那这一次登录处理的过程就是一个轨迹，从前端应用发来请求到接收到响应，
每一次完备的业务功能处理过程都对应唯一的 TraceId。SpanId步调编号。刚才要实现登录功能需要从服务 A 到服务 C 涉及 3 个微服务处理，按处理前后顺序，
每一个微服务处理时日记都被赋予差别的 SpanId。一个 TraceId 拥有多个 SpanId，
而 SpanId 只能从属于某一个 TraceId。导出标识当前这个日记是否被导出，为 true 的时间说明当前轨迹数据允许被其他链路追踪可视化服务网络展现。 4.2 sleuth工作流程
Spring Cloud Sleuth 的技能实现
技能实现说明AOP（面向切面编程）Sleuth 使用 AOP 技能在方法调用前后拦截，创建新的 Span，并将其与当前请求的 TraceId 和 SpanId 相干联。MDC（Mapped Diagnostic Context）MDC 是一个线程局部存储（ThreadLocal），用于在同一线程中生存 TraceId 和 SpanId 等上下文信息。Sleuth 在每个请求的处理过程中将这些信息存储在 MDC 中，从而确保在整个请求处理链中都可以访问这些值。Filter 机制Sleuth 使用 Spring 的过滤器机制（如 OncePerRequestFilter）在每个 HTTP 请求的生命周期内举行处理，确保每个请求都有 TraceId 和 SpanId，并将它们通报给下游服务。 Spring Cloud Sleuth 的工作流程
流程说明备注请求进入应用当一个 HTTP 请求进入微服务应用时，Spring Cloud Sleuth
会自动生成一个 TraceId。
如果请求头中包罗 X-B3-TraceId（比方，来自另一个微服务的请求）
它会使用该 TraceId。如果请求中没有，则 Sleuth 会为其生成一个新的 TraceId。1. TraceId：通常是一个 16 位的长整型数字，用于标识整个请求链路。
2. SpanId：生成一个新的 SpanId，表示请求处理的当前服务操作。生成 Span操作节点每次进入新的操作时（比方，在控制器、服务层方法等），Sleuth 会自动生成一个新的 Span。每个 Span 会关联一个父 SpanId，形成一条追踪链。1. 如果请求已经存在 TraceId，新的 Span 会以该 TraceId 为父，而将新的 SpanId 与请求的操作关联。
2. 如果是第一个操作，则使用生成的 TraceId 和 SpanId。通报 TraceId 和 SpanIdSpring Cloud Sleuth 会通过 HTTP 请求的头部（如 X-B3-TraceId 和 X-B3-SpanId）将 TraceId 和 SpanId 通报到下游服务。1. 每个微服务在接收到请求后，会自动检查请求头部是否包罗 X-B3-TraceId，如果有，则提取并使用。如果没有，Sleuth 会生成一个新的 TraceId。
2. 通过通报 TraceId，服务可以追踪请求在整个微服务链中的活动。日记中输出 TraceId 和 SpanId在应用的日记中，Sleuth 会通过 MDC 将 TraceId 和 SpanId 自动放入日记上下文。你可以在日记格式中使用 %X{X-B3-TraceId} 和 %X{X-B3-SpanId} 来输出这些值，资助你追踪请求的流转过程服务之间的通信当一个服务调用另一个服务时，Spring Cloud Sleuth 会自动将当前的 TraceId 和 SpanId 通报给下游服务。这个过程是通过修改 HTTP 请求头中的 X-B3-TraceId 和 X-B3-SpanId 来完成的。1. 如果下游服务没有通报 X-B3-TraceId，它将会新生成一个 TraceId。
2. 下游服务会创建新的 Span，继承与父 SpanId 关联，从而形成一个完备的链条。 5. 集成zipKin
Spring Cloud Sleuth 支持与分布式跟踪系统（如 Zipkin 或 OpenTelemetry）集成，从而可以或许在 UI 上查看整个请求链的环境。
5.1 添加 Zipkin 相干依赖
<!-- 该依赖是spring-cloud-starter-sleuth 和spring-cloud-sleuth-zipkin 组合
不要再重复添加spring-cloud-starter-sleuth 依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
等价于
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-sleuth-zipkin</artifactId>
</dependency>
注意如果使用spring-cloud-starter-zipkin依赖 需要去掉 之前配置的sleuth依赖 否则zipkin UI无法获取到链路信息
5.2 安装zipkin服务
zipkin官网官网教程中提供了多种方式安装docker、java运行、下载源码打包运行(需要java版本17以及以上)、homebrew下载
这里使用简单jar下载并运行
下载zipkin jar包
选择自己下载的版本举行下载
https://i-blog.csdnimg.cn/direct/f87ab34bf24b4fb9a2f58581e1a3f981.png#pic_center
#运行zipkin
java -jar zipkin-server-2.9.4-exec.jar
#运行zipkin 静默启动
nohup java -jar zipkin-server-2.9.4-exec.jar > zipkin.log 2>&1 &
5.3 配置 Zipkin 地址
spring:
zipkin:
# Zipkin 后端服务的地址
base-url: http://localhost:9411/
5.4 访问 Zipkin UI
只要有http请求配置sleuth和zipkin服务，对应的链路都会被zipkin网络起来，并在zipkin UI上举行查看。
访问 http://localhost:9411/ 就可以使用ui页面举行查看链路了（访问一下服务，才会有数据）。
zipkin UI页面
https://i-blog.csdnimg.cn/direct/a469c9703ddb426cb08c7ed0ed574360.png#pic_center
链路详情
https://i-blog.csdnimg.cn/direct/1f8a8615b939440fbbef9ed941124d6f.png#pic_center
依赖分析
https://i-blog.csdnimg.cn/direct/c79c895f06bc47cbbee218182d6dc808.png#pic_center
6. 集成SkyWalking
SkyWalking 是一个开源的分布式追踪和性能监控平台，支持应用的分布式追踪、应用性能管理 (APM)、服务监控等。它与 Spring Cloud 的集成可以资助你及时监控微服务架构中的请求流向、性能瓶颈等。
下面是 Spring Cloud 集成 SkyWalking 的详细步调。
6.1 安装skyWalking UI
[*] 从安装skyWalking UI 下载最新版本的二进制包（如 apache-skywalking-apm-x.x.x.tar.gz ）注意：6.x.x版本 可以使用jdk8 更高的版本需要使用jdk11。（我的是jdk8 所以下载的是6.6.0）
[*]skywalking-apm-x.x.x.tar.gz 使用默认的存储（比方 H2、RocksDB）。
[*]skywalking-apm-es-x.x.x.tar.gz 使用 Elasticsearch 作为存储后端。
https://i-blog.csdnimg.cn/direct/9af3c3b877a745388611f56203129d71.png#pic_center
[*] 解压后，进入bin目录，启动 SkyWalking OAP 和 UI 服务：
# 启动 OAP 服务
./oapService.sh start
#SkyWalking OAP started successfully!启动成功
# 启动 UI 服务
./webappService.sh start
#SkyWalking Web Application started successfully!启动成功
[*] 默认环境下，SkyWalking UI 访问地址为：http://localhost:8080。
https://i-blog.csdnimg.cn/direct/1efb83c6f44649e1a771deeacccde65b.png#pic_center
skyWalking 目录布局
https://i-blog.csdnimg.cn/direct/5b7c4dccaa8c4c88a3b5e214f13e0ea0.png#pic_center
目录作用内容bin存放启动脚本和工具oap-services.sh / oap-services.bat：启动或停止 OAP 服务的脚本。 webapp.sh / webapp.bat：启动或停止 SkyWalking UI 的脚本。 其他工具脚本，如配置生成、日记整理等。config存放配置文件application.yml：OAP 服务的核心配置文件，包罗端口、存储、集群等配置。 agent-config 目录：包罗 SkyWalking Agent 的配置文件，如 agent.config。 其他配置文件，如告警规则、日记配置等。logs存放日记文件oap 目录：OAP 服务的日记文件。 webapp 目录：SkyWalking UI 的日记文件。 其他日记文件，如告警日记、错误日记等。oap-libs存放 OAP 服务的依赖库包罗 OAP 服务运行所需的全部 JAR 包和依赖库。webapp存放 SkyWalking UI 的前端文件包罗前端静态资源（如 HTML、CSS、JavaScript）。 配置文件 webapp.yml，用于配置 UI 的访问端口、后端地址等。agent存放 SkyWalking Agent 的文件（可选）包罗 Agent 的核心 JAR 包和插件。 配置文件 agent.config，用于配置 Agent 的收罗计谋、后端地址等。licenses存放许可证文件（可选）包罗 SkyWalking 的开源许可证文件（如 Apache License 2.0） 6.2 Maven 依赖
如果你的项目是基于 Maven 的，你需要在 pom.xml 文件中添加如下依赖：
<dependency>
<groupId>org.apache.skywalking</groupId>
<artifactId>apm-toolkit-logback-1.x</artifactId>
<version>9.0.0</version>
</dependency>
<dependency>
<groupId>org.apache.skywalking</groupId>
<artifactId>apm-toolkit-trace</artifactId>
<version>9.0.0</version>
</dependency>
6.3.配置 SkyWalking Agent
SkyWalking 使用 Java Agent 举行自动化的分布式追踪，因此你需要下载并配置 SkyWalking Java Agent。
下载 SkyWalking Agent
[*]前去 SkyWalking 官网 下载最新的 SkyWalking Agent。
[*]解压下载的文件，你会看到一个名为 agent 的文件夹，内里包罗了 skywalking-agent.jar。
上述6.1中安装skyWalking UI下在的tar包里agent 的文件夹，内里包罗了 skywalking-agent.jar。
配置 Java Agent
在 Spring Boot 应用的启动命令中，指定 SkyWalking 的 Java Agent。
java -javaagent:/${path}/skywalking-agent.jar \
-Dskywalking.agent.service_name=${your-service-name} \
-Dskywalking.collector.backend_service=localhost:11800 \
-Dskywalking.agent.namespace=default \
-jar xxxx.jar
[*]-javaagent:/${path}/skywalking-agent.jar：指定 SkyWalking Agent 的位置。
[*]-Dskywalking.agent.service_name=${your-service-name}：设置应用的服务名称。
[*]-Dskywalking.collector.backend_service=localhost:11800：指定 SkyWalking 后端的地址（默认使用 localhost:11800）。
[*]-Dskywalking.agent.namespace=default：设置命名空间，默认是 default。
确保你将 ${path} 替换为现实的 SkyWalking Agent 路径，${your-service-name} 替换为你的服务名称。
设置采样率
#agent目录下的agent.config 用于配置 Agent 的采集策略、后端地址等。需要打开里面的采样率配置
#每3秒采样的追踪（trace）数量
# 1.全量采集（负数或 0）
# 1.部分采集（正整数，数字越大，采样率越高）
agent.sample_n_per_3_secs=${SW_AGENT_SAMPLE:-1}
agent.config
配置项说明默认值agent.service_name应用在 SkyWalking UI 中展示的服务名称，需为每个服务设置唯一名称。无（必须配置）collector.backend_serviceSkyWalking OAP 后端服务的地址，用于接收探针收罗的数据。127.0.0.1:11800agent.namespace命名空间，用于隔离跨进程传播的 Header，若配置则 Header 将包罗命名空间信息。空字符串agent.sample_n_per_3_secs每 3 秒采样 N 条数据，负数或 0 表示不采样（即全量收罗）。-1（全量收罗）agent.instance_name服务实例的唯一标识，建议在分布式系统中设置，以便区分差别实例。空字符串（需手动配置）agent.authentication鉴权配置，取决于后端是否开启鉴权功能，目前仅实现基本鉴权。空字符串agent.span_limit_per_segment单个 Segment 中 Span 的最大数量，用于估算应用程序内存开销。150agent.ignore_suffix忽略以指定后缀结尾的 Segment，比方 .jpg, .css 等静态资源请求。空字符串logging.level日记级别，可选值包括 DEBUG, INFO, WARN, ERROR。DEBUGlogging.file_name日记文件名，默认输出到 skywalking-api.log。skywalking-api.logplugin.mongodb.trace_param是否记载 MongoDB 访问的参数信息，true 表示记载，false 表示仅记载操作名。falseplugin.elasticsearch.trace_dsl是否记载 Elasticsearch 的 DSL 查询信息，true 表示记载，false 表示不记载。false 6.4 链路查看
微服务 customer-server、order-server两个为服务：拓扑关系如下：
https://i-blog.csdnimg.cn/direct/c0ef70b8bcb44b58b0522ba642327169.png#pic_center
访问http请求，查看日记是否有链路数据，同时skywalking 网络到链路数据
日记数据
https://i-blog.csdnimg.cn/direct/df33b32bd9f443898fc7b6681be4a551.png#pic_center
https://i-blog.csdnimg.cn/direct/39ecdfbcfcde4af1a87e53b5197bfa74.png#pic_center
skyWalking 网络的日记数据
https://i-blog.csdnimg.cn/direct/9a19d2429b504f65aa217a0f819406d0.png#pic_center
6.5 skywalking 原理
SkyWalking 的架构
SkyWalking 采用客户端-服务器架构，重要由以下几个核心组件构成：
核心组件说明SkyWalking Agent在应用程序中部署，负责网络应用程序的性能数据，并将这些数据发送到 SkyWalking OAP举行处理和存储。SkyWalking OAP作为数据处理和分析平台，OAP 负责接收来自 Agent 的数据，对其举行存储、分析，
并提供 API 和 UI 来查看分析效果。OAP 提供了许多功能模块，如 Trace、Metric、Log 等。SkyWalking UI提供 Web 界面用于查看和分析监控数据，展示系统健康状态、请求链路、性能瓶颈等信息。 数据网络和传输流程
[*] 数据网络
[*]分布式追踪（Distributed Tracing）： SkyWalking 通过 agent 在应用程序中集成追踪功能。当请求进入应用时，agent 会为每个请求生成一个唯一的追踪 ID，并记载请求的执行路径，包括服务调用的链路信息（如方法、接口、调用的微服务等）。
[*]Span：每个追踪的过程被称为一个 Span，比方，调用某个方法、调用一个外部服务等。每个 Span 记载了执行的时间、状态、错误等信息。
[*]指标网络： 除了追踪信息，SkyWalking 还会网络应用程序的各种性能指标，如 CPU 使用率、内存使用、请求吞吐量等。通过定时上报这些指标，用户可以了解系统的运行状态。
[*]日记网络： SkyWalking 还可以网络应用程序的日记，并将日记与 Trace 数据关联起来，便于用户举行题目排查和分析。
[*] 数据传输
[*]gRPC 通道： SkyWalking Agent 将网络到的数据通过 gRPC 协议发送给 SkyWalking OAP。gRPC 是一个高效的长途过程调用框架，实用于微服务环境中的高并发数据传输。
[*]数据格式： 数据以特定的格式（如 JSON 或 Protocol Buffers）传输，包罗 Trace 数据、指标数据、日记等内容。
[*] 数据存储与分析
[*]OAP 处理与存储： 在接收到 Agent 发送的数据后，SkyWalking OAP 会对数据举行处理，存储在内存或数据库中。OAP 提供的分析模块会对数据举行处理，分析应用程序的性能瓶颈、服务依赖关系、错误和非常等。
[*]查询和分析： 用户可以通过 SkyWalking 提供的 UI 查询和分析数据，查看应用的整体健康状况、链路追踪、性能瓶颈等信息。
SkyWalking 数据模子
数据模子说明Trace一个 Trace 代表了一个请求的执行路径，包罗了多个 Span。
Span：每个 Span 代表一个操作的时间范围，通常是一个函数调用或一个长途服务的调用。
Segment：一组 Span，通常表示一个微服务的生命周期，包罗多个步调或服务调用。Metrics表示系统的性能指标，如吞吐量、响应时间、CPU 使用率等。Logs与 Trace 相干联的日记信息，用于资助分析题目。 分布式追踪的工作原理
在分布式系统中，一个请求通常会跨多个服务举行调用，SkyWalking 通过以下方式实现分布式追踪：
[*]请求进来时，SkyWalking 会生成一个唯一的 Trace ID，并将其附加到请求的全部后续调用中。
[*]每个服务都会生成一个 Span，记载该服务的请求信息，并将它发送到 SkyWalking OAP。
[*]OAP 会将多个服务的 Span 组合在一起，形成一个完备的 Trace，并通过 UI 体现各服务之间的调用链路。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]