当前位置：首页 > news >正文

链路追踪组件学习

news 来源：原创 2025/9/16 21:36:55

- 1. 为啥需要链路追踪
- 2. 常见的链路追踪组件
- 3. 使用过的链路追踪组件
- - 3.1. Spring Cloud Sleuth
  - 3.2. Zipkin
  - 3.3. Apache SkyWalking
- 4. 集成Spring Cloud Sleuth框架
- - 4.1. 流程步骤
  - 4.2 sleuth工作流程
- 5. 集成zipKin
- - 5.1 添加 Zipkin 相关依赖
  - 5.2 安装zipkin服务
  - 5.3 配置 Zipkin 地址
  - 5.4 访问 Zipkin UI
- 6. 集成SkyWalking
- - 6.1 安装skyWalking UI
  - 6.2 Maven 依赖
  - 6.3.配置 SkyWalking Agent
  - 6.4 链路查看
  - 6.5 skywalking 原理

1. 为啥需要链路追踪

在分布式系统中，链路追踪是非常重要的工具，主要原因如下：

解决微服务间的调用追踪问题

在传统的单体应用中，所有的逻辑和请求都发生在一个进程内，系统的行为相对简单，问题的定位也相对直接。

然而，随着系统架构变为分布式（尤其是微服务架构），请求通常会在多个服务间流转，这使得问题的定位变得更加困难。链路追踪可以帮助开发者跟踪每个请求在各个微服务之间的传播，确保在分布式环境中也能全面了解请求的路径。

提高故障定位和排查效率

在分布式系统中，服务间的调用链条往往非常复杂，可能会涉及多个服务、数据库和其他资源。在出现问题时（如延迟、错误、服务不可用等），开发者很难知道问题发生在哪一层级。
链路追踪通过记录请求从一个服务到另一个服务的全过程，包括服务的响应时间、调用关系、错误信息等，使得开发者可以快速定位到问题所在的具体服务和操作。

性能瓶颈分析

分布式系统中的请求通常跨多个服务和机器，性能瓶颈可能出现在某个具体服务或接口上。链路追踪能够显示每个请求的时间分布，帮助开发者找到响应时间长的服务，从而优化性能。
通过链路追踪，可以清晰看到各个微服务之间的调用时间、排队时间以及响应时间，快速发现系统瓶颈。

监控和可视化

现代分布式系统需要持续的监控和分析。链路追踪不仅能够收集服务的调用数据，还能够将这些数据通过可视化工具（如 Zipkin、skyWalking 等）展示出来，帮助开发者或运维人员更直观地了解系统的健康状况。
通过图形化的方式查看服务之间的调用关系和依赖关系，有助于理解系统的架构，并发现潜在的问题和优化空间。

2. 常见的链路追踪组件

在进行链路追踪工具的选型时，需要考虑多个方面，以确保所选方案能够有效满足系统的需求。以下是一些关键考量因素：

维度	Spring Cloud Sleuth	Zipkin	Jaeger	OpenTelemetry	Elastic APM	Prometheus + Grafana	Apache SkyWalking	DataDog APM
技术栈兼容性	高（Spring 系列）	高（Java、Spring）	高（多语言支持）	高（多语言支持）	高（多语言支持）	中（主要为度量工具，链路追踪需要集成）	高（多语言支持）	高（多语言支持）
功能特性	自动化追踪，日志集成	分布式追踪，存储查询	分布式追踪，高性能监控	跨语言支持，综合追踪	性能监控，事务追踪	度量监控，需配合链路追踪	高（分布式追踪、APM）	性能监控，事务追踪
存储与查询能力	依赖 Zipkin 存储	支持内存和其他存储后端	分布式存储，查询强大	灵活，支持多种后端	支持 Elastic Stack	Prometheus 存储，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 长度为16trace-id-length: 16sampler:#链路追踪采样率 #采样率 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 来标识和追踪请求的生命周期。其核心概念包括：
在这里插入图片描述

TraceId：一个全局唯一的标识符，代表整个请求的生命周期。每个请求从入口服务到最终服务都有相同的 TraceId。
SpanId：表示单个操作或请求的执行段，每个 Trace 会包含多个 Span。每个服务中的每个处理请求的操作都会创建一个新的 Span，并与 TraceId 关联。
Parent SpanId：表示当前 Span 的父 Span，如果一个请求是由另一个请求引发的，它会继承上一个请求的 SpanId 作为 Parent SpanId。

格式	说明
微服务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 和 SpanId	Spring 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包

选择自己下载的版本进行下载
在这里插入图片描述

#运行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页面
在这里插入图片描述
链路详情

依赖分析
在这里插入图片描述

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 作为存储后端。

解压后，进入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。

skyWalking 目录结构
在这里插入图片描述

目录	作用	内容
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_service`	SkyWalking OAP 后端服务的地址，用于接收探针采集的数据。	`127.0.0.1:11800`
`agent.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 的最大数量，用于估算应用程序内存开销。	`150`
`agent.ignore_suffix`	忽略以指定后缀结尾的 Segment，例如 `.jpg`, `.css` 等静态资源请求。	空字符串
`logging.level`	日志级别，可选值包括 `DEBUG`, `INFO`, `WARN`, `ERROR`。	`DEBUG`
`logging.file_name`	日志文件名，默认输出到 `skywalking-api.log`。	`skywalking-api.log`
`plugin.mongodb.trace_param`	是否记录 MongoDB 访问的参数信息，`true` 表示记录，`false` 表示仅记录操作名。	`false`
`plugin.elasticsearch.trace_dsl`	是否记录 Elasticsearch 的 DSL 查询信息，`true` 表示记录，`false` 表示不记录。	`false`

6.4 链路查看

微服务 customer-server、order-server两个为服务：拓扑关系如下：
在这里插入图片描述
访问http请求，查看日志是否有链路数据，同时skywalking 收集到链路数据

日志数据
在这里插入图片描述

skyWalking 收集的日志数据
在这里插入图片描述

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 显示各服务之间的调用链路。

目录