微服务调用链追踪实战：用 SkyWalking 实现全链路可视化与故障溯源

某电商平台在 "618" 大促期间，用户反馈 "提交订单后长时间无响应"，运维团队排查时陷入困境：订单服务调用了库存、支付、物流 3 个下游服务，每个服务又部署了多个实例，仅能通过日志零散看到 "调用支付服务超时" 的信息，却无法确定是订单服务自身处理缓慢、支付服务响应延迟，还是中间网络链路故障；更无法得知整个调用链的耗时分布（如订单服务处理耗时 100ms，调用库存服务耗时 500ms，调用支付服务耗时 3000ms），导致故障排查耗时 4 小时，严重影响用户体验与平台营收。这正是微服务架构下调用链管理的典型痛点：链路不可见、性能瓶颈难定位、故障溯源效率低。本文将以 Apache SkyWalking 为核心，结合微服务探针埋点，构建覆盖 "调用链采集、链路可视化、性能分析、故障告警" 的全链路追踪体系，让微服务间的交互过程清晰可追溯。

一、微服务调用链追踪的核心痛点与价值

1. 传统调用链管理的四大痛点

在微服务架构中，一个用户请求往往需要经过多个微服务的协同处理（如 "用户下单" 需调用订单、库存、支付、物流服务），传统 "无追踪" 或 "零散日志追踪" 的方式存在明显缺陷：

• 链路不可见，交互黑盒化：无法直观看到一个请求从入口到出口的完整调用路径（如 "用户请求→网关→订单服务→库存服务→支付服务"），当出现超时或错误时，无法确定故障发生在哪个服务或哪个调用环节；

• 性能瓶颈难定位：仅能看到最终接口的响应时间（如 "下单接口响应时间 4000ms"），无法拆分各服务、各调用环节的耗时（如 "网关转发 50ms、订单服务处理 100ms、库存服务耗时 500ms、支付服务耗时 3350ms"），难以定位性能瓶颈所在；

• 故障溯源效率低：当某个服务返回错误时（如支付服务返回 "数据库连接超时"），无法快速关联上游调用方（如订单服务）的请求参数、下游依赖服务（如支付数据库）的状态，需在多个服务的日志中手动查找关联信息，溯源耗时极长；

• 分布式事务问题难排查：微服务间的分布式事务（如 "下单成功后扣减库存、创建支付单"）若出现部分成功部分失败的情况（如下单成功但库存未扣减），无法通过调用链追溯各服务的事务执行状态，难以定位事务不一致的原因；

• 服务依赖关系模糊：随着微服务数量增加（如超过 50 个），人工难以维护准确的服务依赖关系图（如 "订单服务依赖库存、支付、用户服务，库存服务又依赖商品、仓储服务"），当某个服务下线或升级时，无法快速评估对其他服务的影响范围。

物流服务调用链困境：

用户下单后，物流服务需调用仓储服务查询库存位置、调用配送服务分配快递员，某次用户反馈 "下单后物流信息长时间未更新"，运维团队仅能看到物流服务日志中 "调用配送服务返回超时"，但无法确定是配送服务自身故障，还是物流服务到配送服务的网络延迟，或是配送服务依赖的地图服务故障，排查 2 小时后才发现是配送服务的数据库连接池耗尽。

2. 调用链追踪的核心价值

一套完善的微服务调用链追踪体系（如基于 SkyWalking 构建），能系统性解决上述痛点，核心价值体现在：

• 全链路可视化：直观展示用户请求的完整调用路径（从入口网关到下游所有依赖服务），包括每个调用环节的服务名称、实例 IP、调用方式（同步 / 异步）、返回状态（成功 / 失败），让链路交互过程透明化；

• 性能瓶颈精准定位：拆分每个调用环节的耗时（如 "服务内处理耗时、网络传输耗时、下游服务响应耗时"），通过耗时排序快速定位性能瓶颈（如 "支付服务单次调用耗时 3000ms，占总耗时的 75%"）；

• 故障根因快速溯源：当调用链中出现错误时（如返回 500 错误、超时），可直接查看错误服务的详细日志（如错误堆栈）、请求参数（如订单号、用户 ID）、上下游调用上下文，无需跨工具切换，大幅缩短故障溯源时间；

• 服务依赖关系自动绘制：基于调用链数据自动生成服务依赖关系图（如 "订单服务→库存服务→商品服务"），支持按调用频次、耗时统计依赖强度，帮助运维团队清晰掌握服务间的关联关系；

• 分布式事务状态追踪：关联分布式事务 ID（如 Seata 的 XID）与调用链 ID，展示各服务的事务执行状态（如 "订单服务事务提交成功、库存服务事务提交失败"），快速定位事务不一致的原因；

• 容量规划与优化依据：基于调用链的 QPS、耗时数据，分析各服务的性能容量（如 "订单服务单实例支撑 QPS 500，平均耗时 100ms"），为服务扩容、性能优化（如缓存优化、SQL 优化）提供数据支撑。

3. 主流调用链追踪工具对比

|-----------------------|-----------------------------------------------|------------|----------------------------|-----------------------|---------------------------|
| 工具 | 核心优势 | 部署复杂度 | 探针侵入性 | 链路可视化 | 适用场景 |
| Apache SkyWalking | 国产开源、中文文档丰富、支持多语言探针、与 Spring Cloud/Dubbo 深度集成 | 中 | 低（无侵入式探针） | 强（支持服务拓扑、调用链详情、性能仪表盘） | 中大型微服务集群、国产化需求场景 |
| Jaeger | CNCF 毕业项目、与 Kubernetes 原生集成、支持 OpenTelemetry | 中 | 中（需手动集成 SDK） | 中（基础链路可视化） | 云原生微服务、OpenTelemetry 生态用户 |
| Zipkin | 部署简单、轻量级、支持多种存储（Elasticsearch、MySQL） | 低 | 中（需集成 Spring Cloud Sleuth） | 中（基础链路与依赖图） | 中小型微服务、快速搭建场景 |
| Pinpoint | 无侵入式探针（字节码增强）、支持大规模集群、实时监控 | 高 | 低 | 强（支持服务实例级监控） | 大型企业级微服务、高并发场景 |
| Datadog APM | 全栈监控集成（调用链 + 日志 + 指标）、AI 辅助性能分析、SaaS 化部署 | 低（SaaS 模式） | 低（自动注入探针） | 强（多维度可视化） | 企业级全栈监控、无需自建基础设施场景 |

二、调用链追踪核心技术：原理与关键概念

1. 调用链追踪的核心原理

调用链追踪的核心是通过 "探针埋点" 采集服务间的调用数据，再通过 "追踪系统" 对数据进行聚合、分析、可视化，核心原理包括：

• 分布式追踪三大要素（Google Dapper 论文提出）：

1. 1. Trace：一个用户请求从入口到出口的完整调用链路，由多个 Span 组成，用唯一的traceId标识；例如 "用户下单" 请求对应的 Trace，包含网关、订单、库存、支付服务的调用 Span；

1. 1. Span：Trace 中的一个独立调用环节（如 "订单服务调用库存服务""库存服务查询数据库"），用唯一的spanId标识；每个 Span 包含调用方、被调用方、开始时间、结束时间、耗时、状态（成功 / 失败）等信息；

1. 1. Span Context：Span 间的关联信息，包含traceId（全局唯一）、spanId（当前 Span ID）、parentSpanId（父 Span ID，标识当前 Span 的上游调用方），通过网络传输（如 HTTP Header、RPC Metadata）传递给下游服务，确保整个 Trace 的 Span 能被正确关联；

• 探针埋点方式：

1. 1. 无侵入式埋点（推荐）：通过字节码增强（如 SkyWalking、Pinpoint）或 Sidecar 代理（如 Istio）自动采集调用数据，无需修改业务代码；例如 SkyWalking 的 Java 探针通过-javaagent参数挂载，自动拦截 Spring MVC、Dubbo、MySQL 等框架的调用，生成 Span；

1. 1. 侵入式埋点（需手动集成）：通过 SDK（如 Jaeger SDK、Zipkin Brave）在业务代码中手动埋点，例如在订单服务调用支付服务前，手动创建 Span 并传递 Span Context；

• 数据传输与存储：

1. 1. 数据采集：探针采集的 Span 数据（如traceId、spanId、耗时、状态）通过 gRPC/HTTP 协议发送到追踪系统的 Collector（如 SkyWalking OAP Server）；

1. 1. 数据聚合：Collector 对 Span 数据进行聚合，按traceId关联所有 Span，生成完整的 Trace 链路，并计算各 Span 的耗时、错误率等指标；

1. 1. 数据存储：聚合后的 Trace 数据与指标数据存储到数据库（如 SkyWalking 支持 Elasticsearch、MySQL、TiDB），用于后续查询与可视化；

• 可视化与分析：

1. 1. Trace 详情展示：按时间线展示 Trace 中的所有 Span，直观查看各环节的耗时、状态，点击 Span 可查看详细日志、请求参数；

1. 1. 服务拓扑图：基于 Span 的调用关系，自动生成服务依赖图，展示服务间的调用方向、调用频次、平均耗时；

1. 1. 性能仪表盘：统计各服务的 QPS、平均耗时、P95/P99 耗时、错误率等指标，支持按时间维度（如最近 1 小时、最近 24 小时）查看趋势。

2. SkyWalking 核心架构与组件

Apache SkyWalking 是一款开源的分布式追踪与 APM（应用性能监控）工具，核心架构分为四部分，各组件协同工作实现全链路追踪：

• 探针（Agent）：部署在微服务实例中，负责采集调用链数据、服务指标（如 JVM 内存、CPU 使用率）、日志数据；支持多语言（Java、Go、Python、Node.js），Java 探针通过无侵入式埋点（字节码增强）采集数据，无需修改业务代码；

• 后端服务（OAP Server）：全称 OpenAPM Server，是 SkyWalking 的核心处理节点，负责接收 Agent 发送的追踪数据与指标数据，进行聚合、分析、存储；主要功能包括：

1. 1. 接收数据：通过 gRPC 协议接收 Agent 的 Trace、Metric、Log 数据；

1. 1. 数据处理：按traceId聚合 Span 生成 Trace 链路，计算服务的 QPS、耗时、错误率等指标，构建服务拓扑图；

1. 1. 数据存储：将处理后的数据写入存储介质（如 Elasticsearch、MySQL）；

1. 1. 告警管理：基于指标数据（如 "服务错误率超过 5%""调用耗时超过 1000ms"）配置告警规则，触发告警通知；

• 存储（Storage）：用于持久化 Trace 数据、指标数据、服务拓扑数据；SkyWalking 支持多种存储方案，推荐使用 Elasticsearch（适合大规模数据存储与高效查询）；

• 前端 UI（SkyWalking UI）：基于 React 开发的可视化界面，提供 Trace 详情查询、服务拓扑图、性能仪表盘、告警列表等功能，用户可通过浏览器访问（默认端口 8080）。

SkyWalking 数据流转流程：

1. 探针埋点：在订单服务的 Java 应用中挂载 SkyWalking Agent（-javaagent:/path/skywalking-agent.jar -Dskywalking.agent.service_name=order-service -Dskywalking.collector.backend_service=oap-server:11800）；

1. 数据采集：当用户请求 "下单" 时，Agent 自动拦截订单服务的 Spring MVC 接口、调用库存服务的 Dubbo 请求、查询 MySQL 的 SQL 操作，生成多个 Span，每个 Span 包含traceId、spanId、parentSpanId、耗时等信息；

1. 数据传输：Agent 将 Span 数据通过 gRPC 协议发送到 OAP Server 的 11800 端口；

1. 数据处理：OAP Server 接收 Span 数据，按traceId关联所有 Span（如 "网关→订单服务→库存服务→MySQL" 的 Span），计算订单服务的 QPS（如每秒 100 次调用）、平均耗时（如 150ms），并构建服务拓扑图（订单服务依赖库存服务、MySQL）；

1. 数据存储：OAP Server 将 Trace 数据（完整链路）与指标数据（QPS、耗时）写入 Elasticsearch；

1. 可视化查询：用户通过 SkyWalking UI 查询 "traceId=abc123" 的 Trace 详情，查看各 Span 的耗时分布，或查看订单服务的性能仪表盘，分析最近 1 小时的耗时趋势。

三、实战：基于 SkyWalking 构建微服务调用链追踪体系

1. 环境准备

• 基础环境：Linux 服务器（CentOS 7+/Ubuntu 20.04+）、JDK 11+（SkyWalking Agent 与 OAP Server 依赖）、Docker 20.10+（可选，用于快速部署 Elasticsearch 与 SkyWalking）；

• 工具版本：SkyWalking 9.7.0（稳定版）、Elasticsearch 7.17.0（与 SkyWalking 兼容）；

• 资源需求：

• • OAP Server：至少 2 核 CPU、4GB 内存（生产环境建议 4 核 8GB+，支持集群部署）；

• • Elasticsearch：至少 2 核 CPU、4GB 内存（生产环境建议 3 节点集群，每节点 4 核 8GB+）；

• • SkyWalking UI：轻量级，1 核 CPU、2GB 内存即可；

• • Agent：每个微服务实例额外占用约 50MB 内存，对 CPU 影响极小（

2. 部署 SkyWalking 核心组件（Docker Compose）

采用 Docker Compose 快速部署 Elasticsearch、SkyWalking OAP Server、SkyWalking UI，避免复杂的环境配置，核心配置文件如下：

2.1 Docker Compose 配置文件（docker-compose-skywalking.yml）

version: '3.8'

services:

# 1. Elasticsearch：存储SkyWalking的Trace数据、指标数据

elasticsearch:

image: elasticsearch:7.17.0

container_name: skywalking-elasticsearch

environment:

- discovery.type=single-node # 单节点模式（生产环境需配置集群）

- ES_JAVA_OPTS=-Xms2g -Xmx2g # 堆内存配置（建议为物理内存的50%）

- xpack.security.enabled=false # 关闭安全认证（生产环境需开启）

- "ES_PATH_CONF=/usr/share/elasticsearch/config"

volumes:

- es-data:/usr/share/elasticsearch/data # 数据持久化

- ./elasticsearch/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml # 自定义配置

ports:

- "9200:9200" # HTTP端口（OAP Server连接用）

- "9300:9300" # TCP端口（集群模式节点通信）

networks:

- skywalking-network

healthcheck:

test: ["CMD", "curl", "-f", "http://localhost:9200/_cluster/health"]

interval: 10s

timeout: 10s

retries: 5

# 2. SkyWalking OAP Server：核心处理节点，接收Agent数据并处理

oap-server:

image: apache/skywalking-oap-server:9.7.0

container_name: skywalking-oap-server

depends_on:

elasticsearch:

condition: service_healthy # 等待Elasticsearch健康后启动

environment:

- SW_STORAGE=elasticsearch # 存储类型为Elasticsearch

- SW_STORAGE_ES_CLUSTER_NODES=elasticsearch:9200 # Elasticsearch地址

- SW_HEALTH_CHECKER=default # 启用健康检查

- SW_TELEMETRY=prometheus # 启用Prometheus指标暴露（可选）

- JAVA_OPTS=-Xms2g -Xmx2g # 堆内存配置

ports:

- "11800:11800" # gRPC端口（Agent发送数据用）

- "12800:12800" # HTTP端口（UI查询数据用、健康检查）

networks:

- skywalking-network

healthcheck:

test: ["CMD", "curl", "-f", "http://localhost:12800/health"]

interval: 10s

timeout: 10s

retries: 5

# 3. SkyWalking UI：可视化界面，提供Trace查询、拓扑图、仪表盘

skywalking-ui:

image: apache/skywalking-ui:9.7.0

container_name: skywalking-ui

depends_on:

oap-server:

condition: service_healthy

environment:

- SW_OAP_ADDRESS=http://oap-server:12800 # 连接OAP Server的地址

- SW_UI_PORT=8080 # UI访问端口

ports:

- "8080:8080" # 外部访问端口（浏览器访问）

networks:

- skywalking-network

# 数据卷：持久化Elasticsearch数据

volumes:

es-data:

driver: local

# 网络：SkyWalking组件内部通信网络

networks:

skywalking-network:

driver: bridge

2.2 Elasticsearch 配置文件（elasticsearch/config/elasticsearch.yml）

cluster.name: skywalking-es-cluster

node.name: es-node-1

network.host: 0.0.0.0 # 允许外部访问

http.port: 9200

# 日志存储优化（可选）

indices.query.bool.max_clause_count: 4096

indices.memory.index_buffer_size: 30%

# 关闭内存交换（提升性能）

bootstrap.memory_lock: true

2.3 启动 SkyWalking 组件

# 1. 创建所需目录与配置文件

mkdir -p ./elasticsearch/config

# 2. 写入Elasticsearch配置文件（内容如上）

vim ./elasticsearch/config/elasticsearch.yml

# 3. 为Elasticsearch数据目录授权（避免权限问题）

chmod -R 777 ./elasticsearch/data

# 4. 启动容器（后台运行）

docker-compose -f docker-compose-skywalking.yml up -d

# 5. 查看启动状态（确认所有容器均为Up状态）

docker-compose -f docker-compose-skywalking.yml ps

# 6. 查看OAP Server日志（确认无错误）

docker logs -f skywalking-oap-server

# 7. 访问SkyWalking UI（确认部署成功）

# 浏览器访问http://<服务器IP>:8080，默认无账号密码，进入UI界面即成功

3. 微服务集成 SkyWalking Agent（无侵入式埋点）

SkyWalking Agent 支持多语言微服务，这里以 Java 微服务（Spring Boot）为例，介绍如何集成 Agent 实现无侵入式调用链采集：

3.1 下载 SkyWalking Agent

从 SkyWalking 官网（https://skywalking.apache.org/downloads/）下载 9.7.0 版本的 Agent 压缩包，解压后得到skywalking-agent目录，核心文件包括：

• skywalking-agent.jar：Agent 核心 jar 包；

• config/agent.config：Agent 配置文件（如服务名、OAP Server 地址）；

• plugins/：各类框架的探针插件（如 Spring Boot、Dubbo、MySQL、Redis 插件）。

3.2 配置 Agent（config/agent.config）

修改 Agent 配置文件，指定服务名、OAP Server 地址等关键参数：

# 1. 微服务名称（在SkyWalking UI中显示的服务名，需唯一）

agent.service_name=order-service

# 2. OAP Server地址（gRPC端口，与docker-compose中OAP Server的11800端口对应）

collector.backend_service=192.168.1.100:11800

# 3. 采样率配置（生产环境建议根据流量调整，默认100%采样）

# 全量采样（适合测试环境）

agent.sample_rate=100

# 固定采样数（适合高流量生产环境，如每秒最多采样5个Trace）

# agent.sample_rate=5

# 4. 日志集成（将业务日志关联到调用链，可选）

# 启用日志关联（需配合logback/log4j2配置）

plugin.toolkit.log.grpc.reporter.server_host=${collector.backend_service:127.0.0.1}

plugin.toolkit.log.grpc.reporter.server_port=${collector.grpc_port:11800}

# 5. JVM监控（采集JVM内存、CPU使用率等指标，默认启用）

plugin.jvm.metrics=true

# 6. 插件配置（启用所需框架的插件，默认已启用主流框架）

# 启用Spring Boot插件

plugin.springboot=true

# 启用Dubbo插件（若使用Dubbo调用）

plugin.dubbo=true

# 启用MySQL插件（采集SQL执行耗时）

plugin.mysql=true

# 启用Redis插件（采集Redis操作耗时）

plugin.redis=true

3.3 集成 Agent 到 Spring Boot 微服务

通过 JVM 参数-javaagent挂载 Agent，无需修改业务代码，有两种集成方式：

3.3.1 本地启动（开发 / 测试环境）

在 Spring Boot 应用的启动脚本（如start.sh）中添加 Agent 参数：

#!/bin/bash

# 定义Agent路径（需替换为实际路径）

AGENT_PATH=/path/to/skywalking-agent/skywalking-agent.jar

# 定义JVM参数（包含Agent配置）

JVM_OPTS="-javaagent:${AGENT_PATH} \

-Dskywalking.agent.service_name=order-service \

-Dskywalking.collector.backend_service=192.168.1.100:11800 \

-Xms512m -Xmx512m"

# 启动Spring Boot应用

java ${JVM_OPTS} -jar order-service-1.0.0.jar

3.3.2 Docker 部署（生产环境）

在 Dockerfile 中添加 Agent 文件，并在启动命令中挂载 Agent：

# 基础镜像（Java 11）

FROM openjdk:11-jre-slim

# 复制SkyWalking Agent到容器内

COPY skywalking-agent /usr/local/skywalking-agent

# 复制Spring Boot jar包到容器内

COPY target/order-service-1.0.0.jar /app/order-service.jar

# 定义启动命令（挂载Agent）

CMD ["java", \

"-javaagent:/usr/local/skywalking-agent/skywalking-agent.jar", \

"-Dskywalking.agent.service_name=order-service", \

"-Dskywalking.collector.backend_service=192.168.1.100:11800", \

"-Xms512m", "-Xmx512m", \

"-jar", "/app/order-service.jar"]

构建并启动 Docker 容器：

# 构建Docker镜像

docker build -t order-service:1.0.0 .

# 启动容器

docker run -d --name order-service -p 8081:8080 order-service:1.0.0

3.3.3 K8s 部署（生产环境）

在 K8s 的 Deployment 配置中，通过volumeMounts挂载 Agent 文件，并在env中配置 Agent 参数：

apiVersion: apps/v1

kind: Deployment

metadata:

name: order-service

namespace: production

spec:

replicas: 2

selector:

matchLabels:

app: order-service

template:

metadata:

labels:

app: order-service

spec:

containers:

- name: order-service

image: registry.example.com/order-service:1.0.0

ports:

- containerPort: 8080

# 挂载SkyWalking Agent（通过ConfigMap或PersistentVolume，这里以ConfigMap为例）

volumeMounts:

- name: skywalking-agent

mountPath: /usr/local/skywalking-agent

# 配置Agent参数与JVM参数

env:

- name: JAVA_OPTS

value: >-

-javaagent:/usr/local/skywalking-agent/skywalking-agent.jar

-Dskywalking.agent.service_name=order-service

-Dskywalking.collector.backend_service=oap-server.monitoring.svc.cluster.local:11800

-Xms512m -Xmx512m

# 定义Agent的ConfigMap（需提前创建，包含skywalking-agent目录下的文件）

volumes:

- name: skywalking-agent

configMap:

name: skywalking-agent-config

创建 Agent 的 ConfigMap（将本地 skywalking-agent 目录下的文件导入）：

# 创建ConfigMap（从本地skywalking-agent目录导入文件）

kubectl create configmap skywalking-agent-config -n production --from-file=/path/to/skywalking-agent/

# 部署Deployment

kubectl apply -f order-service-deployment.yaml

# 查看Pod日志（确认Agent启动成功）

kubectl logs -f -pod-name> -n production

3.4 验证 Agent 集成

1. 发送测试请求：向订单服务发送 "下单" 请求（如curl http://<服务IP>:8081/api/order/create -d '{"userId":123,"productId":456,"quantity":2}'）；

1. 查看 SkyWalking UI：

• • 进入 SkyWalking UI → 左侧菜单 "Trace" → 点击 "查询" 按钮，应能看到刚才请求的 Trace 记录（service_name=order-service）；

• • 点击 Trace 的traceId，进入 Trace 详情页，查看完整的调用链路（如 "order-service→inventory-service→mysql"），确认各 Span 的耗时、状态正常；

1. 查看服务拓扑图：

• • 进入 SkyWalking UI → 左侧菜单 "Topology" → 选择 "Global" 视角，应能看到 order-service 与下游依赖服务（如 inventory-service、mysql）的拓扑关系，确认服务依赖正确展示。

4. 日志与调用链关联（可选）

将业务日志与调用链关联，实现 "点击 Trace 中的 Span 即可查看对应的业务日志"，需在日志框架（如 Logback、Log4j2）中集成 SkyWalking 的日志插件：

4.1 Logback 集成（Spring Boot 默认日志框架）

1. 添加依赖：在 Spring Boot 项目的 pom.xml 中添加 SkyWalking 日志插件依赖（若 Agent 已包含，可跳过）：

.skywalking

m-toolkit-logback-1.x 7.0

1. 修改 logback.xml 配置：添加 SkyWalking 的日志 Appender，将traceId、spanId写入日志，并发送到 OAP Server 关联调用链：

.0" encoding="UTF-8"?>

<configuration>

引入SkyWalking的日志转换器（用于添加traceId、spanId） -->

Word="traceId" converterClass="org.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdConverter"/>

="spanId" converterClass="org.apache.skywalking.apm.toolkit.log.logback.v1.x.SpanIdConverter"/>

控制台输出（包含traceId、spanId） -->

="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">

{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - traceId:%traceId spanId:%spanId - %msg%n>

Appender（将日志发送到OAP Server，关联调用链） -->

YWALKING_LOG" class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.log.GRPCLogClientAppender">

{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} %logger{36}