北陌大叔接手一个整天报警的微服务系统时，你最痛苦的是什么？不是某个接口慢，而是你知道它慢，却不知道它到底慢在哪一环。几十个服务，一次用户点击背后要经过十几个调用，任何一个环节出的问题都可能在日志里伪装成"偶发超时"。这个时候，分布式追踪就是救命的东西。而在众多开源方案里，SkyWalking 是我用过上手最顺的一个。这篇文章要聊的，就是 SkyWalking 理解分布式追踪时绕不开的三个最基础概念：Trace、Span、Segment。搞懂它们，你才能真正看懂 SkyWalking 的追踪数据，也才能在日常排查问题时快速定位到是哪一个服务、哪一段代码拖了后腿。不管你刚接触 APM 体系，还是已经在用 SkyWalking 但一直对概念一知半解，这篇都值得花十分钟看完。
1. 先从一个真实的线上事故聊起：为什么光有日志不够用
1.1 单体时代的“简单”是假象
很多人刚工作那会儿都维护过单体应用。一个应用把所有功能包在一起，一个请求进来，方法调用是线性的：Controller -> Service -> DAO，最多加个缓存和消息队列。那时候排查慢请求的方式很简单：点开日志，找到对应的 request 链路，加上耗时统计，基本就能定位。就算慢，也无非是 SQL 没走索引、接口逻辑写得太重这类问题。
但服务一拆，事情就变味了。用户下单，前端请求先打到网关，接着要调用户服务确认登录态，调订单服务校验库存并落库，调优惠券服务计算折扣，调支付服务生成支付单，中间还有好几次消息队列的异步通知。任何一个环节慢，都会拖垮整个下单接口的响应时间。此时单看某一个服务的日志，你只能看到自己这一段耗时，看不到全局。
1.2 日志串联的痛点：你缺的不是日志，是上下文
有人可能会说，日志里打印 traceId，把它贯穿到所有服务里不就行了？理论上确实可以，但实际做起来非常痛苦。你得保证每个服务都按照同一个规范来生成和透传 traceId，任何一个第三方库忘记传递，这个链路就断了。而且就算 traceId 串起来了，想看一次完整调用，你还得去四个系统里分别查日志，再手工按时间线拼装。这个过程慢且容易出错，尤其在日志量大的时候，很多服务不落全量日志，之前的环节可能已经被冲掉。
我印象特别深的一次事故：线上支付接口平均耗时从 800ms 涨到 3s，表面看所有依赖服务都在正常范围，但总耗时就是下不来。后来是用了 SkyWalking 看了一次完整 Trace，才发现问题出在两个服务之间一个不起眼的 HTTP 重试——某个依赖返回了 502，调用方自动重试了三次，每次等待超时 1 秒。而这个重试动作在单体时代根本不存在，也不会在业务日志里打出来。这就是分布式追踪存在的意义：你需要的是一棵完整的调用树，而不是一堆孤立的日志碎片。
1.3 SkyWalking 的定位：让每条调用都变成一张“地图”
SkyWalking 做的事情，就是在不侵入业务代码的前提下，把所有服务之间的调用关系自动串起来。你只要在服务启动时加上 javaagent，它会自动拦截 HTTP、RPC、数据库、MQ 等主流中间件的调用，把一次请求从入口到出口的完整路径记录下来。它把这条路径抽象成三个核心概念：Trace、Span、Segment。理解了这三个东西，再回头看 SkyWalking 的那张调用关系图、那段火焰图、那些时序列表，都会清晰很多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 官方数据模型拆解：Trace、Span、Segment 分别是什么
2.1 Trace：一次完整业务请求的“全息档案”
Trace 是分布式追踪里最上层的概念。往简单了说，一次外部请求从进入系统到返回结果，中间经历的全部调用和操作，聚合起来就是一条 Trace。它描述的是逻辑上的完整链路，通常用一个全局唯一的 TraceId 来标识。
注意我强调"逻辑上"这三个字，因为 Trace 跟物理上的服务部署位置没有关系。一个 Trace 可以跨三台机器、五个进程、十二个方法调用，但只要它们属于同一次原始请求，就归在同一条 Trace 下。SkyWalking 的前端 UI 里，你在"追踪"页面看到的一个列表项，就是一条 Trace；点进去看到的时间线、调用树，也是这条 Trace 的展开细节。
2.2 Span：一次业务操作的最小追踪单元
Span 是链路追踪的最小粒度，可以理解成"一次具体的操作"。这个操作可以是远程调用、数据库查询、消息发送、或者某一段业务代码。Span 里记录的关键信息包括：
- SpanId：当前 Span 自己的唯一编号
- ParentSpanId：父 Span 的编号，用来构建父子层级关系
- 开始时间、结束时间：用来计算耗时
- Tags：一组键值对，描述这次操作的元数据，比如 HTTP 方法、URL、数据库语句、错误信息
- Logs：操作过程中产生的日志事件，比如异常堆栈、业务标记
一条 Trace 由多少个 Span 组成，取决于这次请求经历了多少步操作。比如网关转发算一个 Span，用户服务查 Redis 算一个 Span，调用订单服务是一个 Span，订单服务查询数据库又是另一个 Span。
2.3 Segment：SkyWalking 独有的“进程内切片”
Segment 可以说是 SkyWalking 相对其他追踪系统最特殊的一个概念，也最容易让人犯迷糊。官方定义里，Segment 是"一个进程内的一次请求处理过程中产生的全部 Span 的集合"。再直白一点：当请求到达某一个服务实例时，从这个服务接收到请求，到它把响应返回给调用方，这整个过程中该服务内部产生的所有 Span，合在一起就是一个 Segment。
一个 Segment 里的 Span 都在同一个线程或同一个处理逻辑链路里，它天然对应着 SkyWalking Agent 内部的一次"Scope"生命周期。Segment 有自己的 SegmentId，同时还会记录这个 Segment 属于哪个 Trace。换句话说：
- Trace 是全局视角，一条 Trace 就像一部电影的全部胶片
- Segment 是局部视角，就像这部胶片在每个拍摄机位录下的那一段素材
- Span 是一个个镜头，是所有素材拼接起来的最小单位
Segment 在 SkyWalking 里的价值是：它让数据的收集和上报送有了一个很好的"打包"单位。Agent 不需要每产生一个 Span 就立即上报，而是等一个 Segment 内的 Span 都生成完，再打包成一个数据单元发送给 OAP 服务端，批量效率更高，也更容易做局部统计。
2.4 三者之间的关系：一张图就能看懂
如果不借助图，可以用一个实际例子来串：用户访问了首页接口，这条请求的完整路径就是一条 Trace；这条请求先打到了网关服务，网关处理过程中产生的所有 Span（比如鉴权、路由转发）构成 Segment A；接着请求跑到商品服务，商品服务里的所有操作 Span 构成 Segment B；最后请求又调用了促销服务，促销服务里查缓存、查数据库的 Span 构成 Segment C。这三个 Segment 通过同一个 TraceId 关联在一起，它们之间通过 Span 的父子关系串联。从全局看，它们是一条完整的 Trace；从局部看，每个服务内部又各自有自己的 Segment。
3. 搞清 Span 的类型和父子关系，才算真正看懂追踪树
3.1 为什么 Span 还要分 EntrySpan、LocalSpan、ExitSpan
只看定义你会发现 Span 就是一个操作单元，但 SkyWalking 在追踪树里给 Span 划分了三种角色，这对于理解服务间的边界特别重要：
- EntrySpan：入口 Span，代表一个服务收到外部请求的那次操作。比如网关服务里拦截到一次 HTTP 请求，这个 Span 就是整个 Segment 的入口。EntrySpan 是跨进程方向的"接收端"。
- ExitSpan：出口 Span，代表这个服务把请求发给下一个服务的那次操作。比如调用订单服务发的 HTTP 客户端请求，就是网关服务 Segment 里的 ExitSpan。ExitSpan 是跨进程方向的"发送端"。
- LocalSpan：本地 Span，不需要跨进程，只是进程内部的某一段逻辑，比如查询本地缓存、执行一个耗时的方法。
一个 Segment 通常有一个 EntrySpan，可能有两个甚至多个 ExitSpan，还有一堆 LocalSpan。理解这三种 Span 之后，你再去看 SkyWalking 的追踪树，就能很清楚地区分：哪里是这个服务自己干的活，哪里是它调用别人，哪里是别人调它。
3.2 父子关系是怎么建立的：ParentSpanId 的逻辑
Span 与 Span 之间通过 ParentSpanId 形成一棵树。很典型的树结构：根 Span 的 ParentSpanId 为空或者为 0，表示它是整条 Trace 的起点。后续每个 Span 都会记录自己是谁的子节点。比如订单服务创建订单之后，又先后调用了库存服务、优惠券服务，那么订单服务里"调用库存服务"这个 ExitSpan，"调用优惠券服务"这个 ExitSpan，它们的父 Span 可能就是"创建订单"这个 LocalSpan，也可能是同一个入口 EntrySpan。
这里有一个容易混淆的点：ParentSpanId 是父 Span 的 ID，而不是父 Segment 的 ID。跨进程传给下游服务的时候，传递的实际上是下游 Segment 的 EntrySpan 的上下文信息。下游收到请求后，会根据上游传递的 TraceId 建立起新的 Segment，并把自己这个 EntrySpan 的 ParentSpanId 指向上游那个 ExitSpan 的 SpanId。这样一来，整个调用链的树关系就跨越了 Segment 的边界，形成了一棵完整的全局追踪树。
3.3 用一次下单请求模拟 Span 的生成过程
为了把上面这些讲得更具体，我模拟一次下单请求，结合 SkyWalking 记录的 Span 形态来看。
用户点击下单，请求先到网关 Gateway。网关里产生 Segment 1，包含：
- EntrySpan：接收用户 HTTP POST /api/order
- ExitSpan：调用用户服务校验登录态（HTTP）
用户服务里产生 Segment 2，包含：
- EntrySpan：接收来自网关的 HTTP 调用
- LocalSpan：查本地 Redis 中的用户会话
- LocalSpan：读取用户等级信息
- ExitSpan：调用订单服务创建订单
订单服务里产生 Segment 3，包含：
- EntrySpan：接收用户服务的调用
- LocalSpan：校验商品库存
- ExitSpan：查询 MySQL 中的商品表
- ExitSpan：查询 MySQL 中的订单表
- LocalSpan：组装订单数据
如果我用 SkyWalking 的 JSON 格式来描述其中一段，大概是下面这个样子。注意这段是示意性的，并不是完整的 OAP 协议格式：
json复制{
"traceId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"segmentId": "segment-order-service-001",
"spans": [
{
"spanId": 0,
"parentSpanId": -1,
"spanType": "Entry",
"operationName": "/api/order/create",
"startTime": 1735000000000,
"endTime": 1735000001200
},
{
"spanId": 1,
"parentSpanId": 0,
"spanType": "Exit",
"operationName": "Mysql/JDBC/OrderMapper.selectById",
"startTime": 1735000000100,
"endTime": 1735000000400
},
{
"spanId": 2,
"parentSpanId": 0,
"spanType": "Local",
"operationName": "OrderServiceImpl.assemble",
"startTime": 1735000000500,
"endTime": 1735000000800
}
]
}
这里 EntrySpan 是根，其余 Span 的 parentSpanId 指向 EntrySpan 的 spanId。真正上报给 OAP 的 Segment 还会带服务名、实例名、trace 状态、时间戳等信息，但核心骨架就是如此。
3.4 从 Span 树到 Topology：为什么 UI 能画出服务依赖图
服务拓扑图是 SkyWalking 很受欢迎的一个功能，它本质上是从海量 Trace 中统计出来的"服务调用关系"。每条 Trace 里，只要出现了"上游服务的 ExitSpan -> 下游服务的 EntrySpan"这种跨进程关系，SkyWalking OAP 就能提取出一次服务与服务的调用记录。把所有 Trace 的这类记录汇总起来，就形成了你在地图页看到的那张节点和连线图。
所以你会发现，拓扑图里的每一条边，本质上都是无数个跨进程 Span 对。如果你在排查问题时发现拓扑图里少了一条边，大概率是这两种情况：要么实际链路里根本没有跨进程调用，都在一个服务内部完成；要么上下文传播失败了，下游服务没有接上 TraceId，导致上下游分别生成了不同的 Trace。后面这种情况我们会在第七节专门展开。
4. Segment 为什么要单独成为一个概念？这是 SkyWalking 设计上很聪明的一环
4.1 为 Agent 的数据收集与上报提供一个自然的边界
很多人第一次接触 SkyWalking 时都会问：既然有了 Trace 和 Span，为什么还要定义一个 Segment？这不是冗余吗？我自己实践下来发现，Segment 的设计非常贴合 Agent 的工作方式。
SkyWalking Java Agent 是基于字节码增强的。请求进来时，Agent 会创建一个 Scope 或类似机制来包裹这段业务逻辑。这个 Scope 对应的恰好就是一次"在当前进程内被处理"的过程。所有在同一个 Scope 内创建的 Span，天然属于同一个 Segment。当 Scope 结束，Segment 也就完整了，Agent 可以立即把这个 Segment 打包、异步发送到 OAP 服务端。注意，它不需要等整条 Trace 在其他服务里的 Segment 都完成，因为那些 Segment 是其他 Agent 负责上报的。这就让数据上报天然支持分布式、高并发场景，每个服务各自上报自己的片段，OAP 再按照 TraceId 把它们组装起来。
4.2 与 OpenTelemetry 模型的对比：Trace/Span 外的另类设计
用过 OpenTelemetry 的朋友应该知道，它的规范里只有 Trace 和 Span，Span 是跨进程上下文传播的最小单元。它并没有一个叫 Segment 的中间层。那 SkyWalking 为什么非要保留 Segment？
我的理解是，Segment 让"进程内资源管理"变得更容易。在 OpenTelemetry 模型里，一个 Span 结束了就可以立刻导出，Span 自己的生命周期和线程绑定关系需要额外处理。在 SkyWalking 模型里，Segment 天然对应了一个处理单元的完整生命周期，比如一个 HTTP 请求在 Tomcat 线程里的所有处理。Agent 可以用一个栈来管理当前活跃的 Span，Segment 就是整个栈的上下界。这个设计让 Agent 在捕获上下文时非常自然：进入一个方法时压栈，离开时弹栈，整段请求结束时把整个栈的数据带走。
如果你在迁移老项目，已经用了 SkyWalking 的 agent，同时又想接入 OTel 生态，官方也提供了兼容方案，比如通过 OTLP 上报或者使用 OpenTelemetry 的 SkyWalking exporter。不过那是另一个话题了，本文不展开。重点是你得理解，Segment 的存在是 SkyWalking 为了高性能 Agent 实现而做的务实选择，不是拍脑袋想出来的概念。
4.3 Segment 可能会遇到的一些边界情况
Segment 不是永远只存在于单线程里。SkyWalking 也支持跨线程传播，比如使用了线程池、异步化处理时，Agent 会把当前上下文快照传给新的线程，在新线程里产生的 Span 仍然属于同一个 Segment，还是会有独立的 Segment？这里的实际行为取决于版本和传播机制，比较常见的做法是：通过增强的 Runnable/Callable 传递 ContextSnapshot，让新线程里的 Span 可以挂到同一个 Trace 上，但 Segment 可能会分裂成多个。因为新线程是一个新的执行上下文，SkyWalking 会为它创建新的 Segment。这就是为什么你在 UI 上有时会看到一条 Trace 里有多个 Segment，但它们属于同一个 traceId。
如果你遇到异步场景下的追踪链路不完整，不用太慌，大概率不是 Agent 有问题，而是你用的异步手段不在默认增强范围内，比如自定义线程池没有传递上下文。这个后面实践部分会提到怎么处理。
5. 从 Trace 的视角看整条链路：一个完整请求的追踪数据长什么样
5.1 UI 里如何查看 Trace、Segment、Span
SkyWalking UI 的"追踪"页面，顶部是一个查询条件区，你可以按时间范围、服务名、TraceId、端点名去过滤 Trace 列表。列表里每一条记录都是一次完整的请求 Trace，即一条 Trace。点击某一条 Trace 后，会进入详情页。
详情页有两种典型视图：
- 树状视图：以 Span 为节点，按调用层级展开，每一行展示 Span 的 operationName、服务名、耗时、状态。展开每个 Span 可以看到 Tags 和 Logs。
- 时间线视图：把 Span 按时间轴平铺，直观看到哪个 Span 耗时最长，是否有串行变并行的情况。
在这个详情页里，你看到的大多数"节点"是独立 Span，但可以看到它们的归属服务。如果鼠标悬停或点击某个 Span，通常能看到它所属的 Segment 信息。有些版本的 UI 在树节点上会显示服务实例名——其实这里隐藏的边界就是 Segment 的边界，同一个服务实例下的连续节点往往属于同一个 Segment。
5.2 换个角度：局部视图与全局视图
很多人在 UI 上会看到一张"调用链展开图"，从根 Span 一直展开到最深的子 Span。这时你可以试着以 Segment 为边界，把它切分成几段。每一次"服务名出现变化"的位置，就是 Segment 切换的位置。比如根节点服务名是 gateway，往下几个节点还是 gateway，到某个节点突然变成 order-service，那么从 gateway 这一侧看，那个节点就是网关的 ExitSpan；从 order-service 这一侧看，它是订单服务的 EntrySpan。理解了这个，你其实就掌握了用 Segment 视角去读追踪树的技巧。
5.3 一次缓慢请求的排查示例：如何利用 Span 耗时定位瓶颈
假设线上一个"查询订单详情"接口从 200ms 涨到了 2s。打开 Trace 详情发现，根 Span（入口请求）耗时 2s，接下来四个子 Span分别是：
| Span | 服务 | 耗时 | 状态 |
|---|---|---|---|
| 接收请求 | order-service | 2s | 成功 |
| 查询 Redis 缓存 | order-service | 2ms | 成功 |
| 查询 MySQL 订单表 | order-service | 1.8s | 成功 |
| 组装响应 | order-service | 15ms | 成功 |
一眼就能看出瓶颈在 "查询 MySQL 订单表" 这个 ExitSpan。点开它的 Tags，能看到 SQL 语句、数据库名、预编译参数等。于是你可以直接拿着这条 SQL 去数据库 EXPLAIN，而不是在代码里加一堆耗时日志去猜。这就是 Span 记录 operationName 和 tags 的价值。
5.4 采样配置会直接影响你能不能看到某条 Trace
默认情况下 SkyWalking 的采样率可能是 100%，但在高并发生产环境，很多人会把采样率调低以避免性能损耗。配置项是 agent.sample_n_per_3_secs，表示每三秒采样多少条请求。如果你的系统量很大，又只设置了很低的采样率，那查 Trace 时看不到某些请求，大概率不是 Bug，而是那些请求没有被采样。
我曾经踩过一个坑：线上流量每秒几千次，我为了减小开销把采样率调到了非常低，结果排查一个偶发报错时，发现报错的请求几乎都未被采样，最终只能临时调高采样率等下一次复现。所以实践中的建议是：核心交易链路的采样率不要一味调低，至少要做到"按 TraceId 强制采样"或"对异常请求强制采样"。SkyWalking 虽然早期版本不支持全量，但现在版本已经有了更灵活的采样策略，你可以按需配置。
6. 跨进程上下文传播：Trace 是如何从 A 服务串到 B 服务的
6.1 魔法背后的 Header 传递机制
SkyWalking Java Agent 之所以能在不改业务代码的情况下串联跨服务调用，靠的是拦截器 + 上下文快照。每当你通过 HTTP Client、Dubbo、gRPC、Kafka 等组件发起调用时，Agent 会拦截到 Request 或者 Carries，然后将一份包含 TraceId、上游 SegmentId、上游 SpanId 的上下文数据写入到请求头里（比如 HTTP 请求头中的 sw8）。下游服务收到请求后，Agent 在入口处再从这个请求头里解析上下文，建立新的 Segment，并把新 EntrySpan 的 ParentSpanId 指向上游 ExitSpan。
所以这个传递过程的完整逻辑是：上游持有的 Span 是 ExitSpan，下游新创建的 Span 是 EntrySpan，它们之间通过请求头传递的上下文形成父子关系。这条"跨进程父 Span -> 下游子 Span"的箭头，正是拓扑图上一条边的来源。
6.2 为什么上下文传递断裂会导致“两条孤立 Trace”
常见的坑是：A 服务通过某个自定义 HTTP 客户端调用 B 服务，这个客户端没有使用常见的 HttpClient 库，而是自己封装了 Socket，或者用了非标准的 REST 库，Agent 的默认插件没有覆盖到它。这时候 A 服务发出的请求是 A 的 Trace，B 服务收到的请求由于没有上下文，会生成一条全新的 Trace。你在 UI 上会看到两条孤立的 Trace，各自看起来都正常，但无法通过 TraceId 串联起来。
另一种常见断裂场景是异步消息。比如你用 RabbitMQ 发送消息，生产者一侧的链路已经结束了，消费者从队列里取到消息后开始处理。如果 Agent 的 MQ 插件支持消息的无头传递，它会把上游 trace 信息塞进消息头和消息属性里，消费者可以接续。但如果你的 MQ 中间件版本不在支持列表里，或者消息经过了网关转换，那链路也会断。
6.3 怎么判断一条 Trace 是否被“切断”
在 SkyWalking UI 搜索时，如果某个入口请求的 Trace 只有一个 Segment，而实际业务代码里明明调用了其他服务，那基本可以断定上下文传递没生效。另外一个判断方法：打开两个服务的拓扑图，如果两个服务之间实际有调用，但拓扑图上没有对应的连线，那十有八九是链路断了。
遇到这种情况，优先检查两件事：一是相关服务的 Agent 版本是否一致，跨版本有时插件行为会有差异；二是调用的中间件是否有对应的 SkyWalking 官方插件或可选插件支持。SkyWalking 支持很多插件，但像自定义协议、Thrift、某些私有 RPC 框架就需要额外在 agent/optional-plugins 目录下启用插件，或者自己写扩展。
6.4 自定义插件做一个“愚公移山”的传递
如果确实没有现成插件，你需要自己继承 gRPC 协议或者用 SkyWalking 的探针 API 在调用链上手动注入上下文。参考做法是：在发送端获取当前 Context，把 traceId、segmentId、spanId 写入自定义请求头；在接收端解析自定义请求头，调用 ContextManager.createEntrySpan 来创建 EntrySpan，并传入解析出的 ContextSnapshot。做这一步的重点是搞清楚接收端创建的 Span 类型必须是 EntrySpan，否则上游的 ExitSpan 无法和下游正确连接。这一段写起来代码不少，但确实能解决绝大多数自定义协议导致的断链问题。
7. 实践视角：理解 Trace、Span、Segment 之后，能解决哪些真实问题
7.1 慢调用排查：从全链路看瓶颈，而不是猜
当你已经会用 Span 的耗时定位瓶颈后，更进阶的用法是横向对比。比如同一个接口，正常情况下 MySQL 查询耗时 50ms，某个时段突然变成 1s，你可以在 SkyWalking 里按时间维度筛选这个端点的 Trace，把多条的 Span 耗时拉出来对比。如果全部慢在同一个 MySQL 语句，那大概率是数据库有慢 SQL、锁等待、连接池打满；如果不同 Span 的花费占比漂移，那可能是 CPU 争抢或网络抖动。这个判断逻辑，只有在你能把请求拆解成 Span 后才能自动化地做。
7.2 错误追踪：Span 的 Logs 里藏着真正的异常
Span 不只是记录耗时，它还记录错误信息。当某个服务返回 500 或抛异常时，Agent 会在对应 Span 的 Logs 里追加一条错误事件，包含异常类型、错误消息、堆栈。当你发现 Trace 状态是"错误"时，直接定位到出错的那个 Span，点开它的 Logs，往往就能看到异常堆栈，省去了登服务器捞日志的功夫。虽然不建议完全依赖它代替日志系统，但作为第一层筛查，效率提升非常明显。
7.3 拓扑巡检：用 Segment 的数量感知服务依赖
这里有一个小技巧：在 SkyWalking 的拓扑图或数据库里，Segment 的数量和 Trace 数量之间有个比例关系。每一个 Segment 代表某个服务实例的一次参与处理。如果你统计某条 Trace 下有 5 个 Segment，说明这次请求经过了 5 次"服务实例处理"边界。对比历史数据，如果某段时间 Segment 数量明显异常增多，比如原本 3 个 Segment 变成了 7 个，很可能是服务调用链变长了——比如某个服务新接入了外部依赖、增加了不必要的中间跳转。这类结构性变化，单看 Trace 列表并不容易发现，但用 Segment 数量做一次聚合分析就非常直观。
7.4 性能开销：正确理解 Agent 对 Span/Segment 的封装成本
很多人担心加了 Agent 会有性能损耗。从我的实践看，SkyWalking Java Agent 对 Span 的创建和 Segment 的封装做了大量复用和池化，单次请求产生的 Span 数量通常不会很多，性能开销在绝大多数业务系统里可以忽略。但如果你的方法里每个小操作都要手动创建大量 LocalSpan，还是建议适度——Span 不是免费的，记录越多的 Span，上报和存储压力越大，也会让追踪树变得又长又碎。所以，自动探针已经覆盖的 HTTP、DB、MQ 调用就够了，真正需要手动埋点的只是那些关键业务步骤，不需要每个循环都埋。
7.5 排查时先看 Trace 还是先看 Segment？一个实用顺序
最后分享一个我自己的排查套路。先看 Trace 列表，锁定异常时间段和异常端点。点进 Trace 详情后，先按服务名聚合看 Segment 分布，确认链路经过了哪些服务边界。然后在耗时最长的 Segment 里找那个耗时最长的 Span，看 Tags 和 Logs。接着再按 Span 类型判断问题属于入口、出口还是本地逻辑。最后结合日志系统做二次确认。这套流程走下来，绝大多数问题都能在十分钟内定位到具体代码或中间件层面，而不是靠经验拍脑袋。
8. 关于采样、存储与数据规模：概念背后的工程现实
8.1 一张 Trace 会占用多少存储
Trace、Span、Segment 这三个概念不仅影响了排查效率，还直接影响存储成本。Segment 是 SkyWalking OAP 接收的最小上报单元，写入存储引擎前，OAP 会把 Segment 数据解析成 Span 相关的记录。如果你用 Elasticsearch 作为存储，每天产生上亿 Span 的索引压力是非常可观的。所以理解 "一条 Trace 会产生多少个 Segment，多少个 Span" 对容量评估很重要。我曾经算过一笔账：一次标准的下单请求产生 3 个 Segment，共 15 个 Span，如果日请求量 1000 万，每天产生的 Span 就是 1 亿 5 千万条。不采样的话，ES 磁盘一天要多出几十 GB。从这个角度看，Trace 模型设计得越节约，存储成本越低。
8.2 采样率与概念观察之间的关系
很多人质疑采样会把问题掩盖掉。这里想说的是，采样不影响 Trace 结构的正确性，只是影响你是否能观察到某一条特定的 Trace。如果系统本身有问题，它很可能在所有采样样本中都会出现，因为你关注的是异常和超时。所以我的建议是：把采样率降低的同时，开启"错误和慢请求强制采样"。这样既控制了存储成本，又保证了当问题真的发生时，你依然能拿到对应的完整 Trace。
8.3 告警中如何利用 Segment/Span 数据
SkyWalking 的告警规则可以基于 Trace 的指标（比如端点的平均响应时间、成功率）去触发。更精细的玩法是结合 Span 采集到的标签数据做维度告警，比如按数据库实例维度计算某条 SQL 的 P99 耗时。理解 Segment 和 Trace 的数据粒度后，你就知道告警规则里的"维度"从哪里来——它来自 Span 的 tags。如果你希望按服务实例、按数据库、按 URI 分别告警，本质上就是在不同标签维度下聚合 Span 数据，而不是只盯着全局平均。
9. 我对新手学习这套概念的一点个人建议
如果你刚接触 SkyWalking，别一开始就去抠 OAP 源码或研究存储结构。最快的路径是：先把自己的项目接上 Java Agent 跑起来，然后在 UI 里反复点开几条 Trace，对着页面上的节点数 Segment 边界和 Span 层级。只有亲眼看到一次请求被拆成树状结构，你对这三个概念的理解才会真正落地。
我自己学这个概念时走过一段弯路，当时死记硬背"Trace 包含 Segment、Segment 包含 Span"这句话，结果一看到具体数据还是懵，因为 UI 里往往只展示 Span，不直接标 Segment。后来我刻意去数"同一服务内连续的 Span 构成一个 Segment"，慢慢就形成条件反射了。这个方法同样推荐给你：看 Trace 详情时，把视角切换到"服务边界"，每换一次服务名就是换了一个 Segment，这样你就能从平面列表里看出三维的链路结构。
还有一个值得养成的习惯：在排查慢请求时，不要只看最外层根 Span 的耗时，一定要逐个展开每个 Segment 的 EntrySpan 和 ExitSpan。很多性能问题发生在服务之间的网络开销、序列化开销和连接池等待上，这些信息只有在跨进程的 Exit/Entry Span 对比中才能体现出来。理解了 Trace、Span、Segment 这些基本概念，等于拿到了一把打开分布式系统黑盒的钥匙，剩下的无非是在实践中越用越熟。