Java 程序员第 46 阶段10：大模型调用链路追踪，SkyWalking 排查线上性能，慢调用与瓶颈定位的 Trace 详情分析与性能剖析

前几篇我们打通了链路透传、修复了异步断点、配置了采样、用拓扑图锁定了瓶颈节点。现在到了最后一公里当拓扑图告诉你「推理服务这一跳很慢」你还需要钻进一条具体的慢 Trace看清它到底慢在哪一段如果慢在 Java 业务侧还要进一步用性能剖析Profile把瓶颈钉到具体方法。本文把「Trace 详情分析」和「性能剖析」两套武器讲透作为本系列收尾。从拓扑下钻到慢调用 TraceTrace 详情页面怎么读Span 树与耗时分布实战解剖一次大模型慢调用性能剖析 Profile把瓶颈钉到方法级连续剖析与最佳实践1. 从拓扑下钻到慢调用 Trace排查路径是一条标准流水线拓扑图定位节点第 09 篇 - 点击节点进入服务仪表盘 - 切到「Trace」标签页 - 按响应时间排序挑出最慢的那几条。SkyWalking 的 Trace 列表已按延迟降序排列并标注了每条 Trace 的总耗时、跨度数量、成功率。点开一条慢 Trace进入 Trace 详情。这一步之前请确认已经开启了合理的采样第 08 篇如果慢调用被采样丢弃列表里就看不到它。好在 slowTraceSegmentThreshold 会强制保留慢链路所以「为什么这么慢」的线索基本不会丢。2. Trace 详情页面怎么读Span 树与耗时分布Trace 详情本质是一棵 Span 树。读懂它关键是区分两个时间**Total Duration总耗时**该 Span 及其所有子 Span 的累计耗时。**Self Duration自身耗时**该 Span 自己执行、不包含子 Span 的时间。判断瓶颈的核心口诀是**谁的总耗时长说明它 subtree 慢谁的自身耗时长说明它自己这个环节在磨洋工**。例如「推理调用」Exit Span 总耗时 3s、自身耗时 3s说明时间全花在等待推理服务返回瓶颈在下游而「提示词组装」Local Span 总耗时 800ms、自身耗时 800ms说明业务逻辑自身慢可能是 JSON 序列化、模板渲染。每个 Span 还带有标签Tags和日志Logs是分析的金矿标签/日志含义排障用途---------http.method / http.urlHTTP 方法与路径定位是哪个接口db.type / db.statement数据库类型与语句定位慢 SQL / 慢向量查询status_code响应状态码区分成功但慢 vs 失败error / log异常堆栈定位报错根因peer对端地址确认下游目标实例在 SkyWalking UI 里Span 树展开后颜色越红代表越慢悬停能看到 self/total 耗时。顺着最红的路径往下点通常三步之内就能定位到具体慢环节。3. 实战解剖一次大模型慢调用假设一条对话 Trace 总耗时 3.4s展开 Span 树如下示例POST /api/chat total 3400ms self 5ms [Entry]├─ buildPrompt total 820ms self 820ms [Local] - 自身慢├─ Redis GET (cache) total 12ms self 12ms [Exit]├─ vectorSearch (HTTP) total 450ms self 450ms [Exit] - 向量检索慢├─ POST /v1/chat/completions total 2050ms self 2050ms[Exit] - 推理慢(下游)└─ postProcess total 60ms self 60ms [Local]分析结论buildPrompt 自身 820ms是业务逻辑瓶颈应检查提示词模板渲染、大对象拷贝、JSON 序列化。vectorSearch 450ms向量检索偏慢应优化索引或降级。POST /v1/chat/completions 2050ms这是下游推理服务耗时结合拓扑图已知推理节点变红根因在 GPU 侧不是 Java 的问题。缓存命中很快12ms说明缓存有效。为了在分析时拿到更多业务维度建议在代码里用 Trace 和 ActiveSpan.tag 给 Span 打上模型名、token 数等标签import org.apache.skywalking.apm.toolkit.trace.Trace;import org.apache.skywalking.apm.toolkit.trace.ActiveSpan;import org.apache.skywalking.apm.toolkit.trace.Tag;Trace(operationName inference.call)Tag(key model, value arg[0].model)public String callInference(ChatRequest req) {// 把关键业务字段写进 Span便于 Trace 列表过滤与下钻ActiveSpan.tag(model, req.getModel());ActiveSpan.tag(promptTokens, String.valueOf(req.getPromptTokens()));ActiveSpan.tag(peer, inference-service:8000);try {return doCall(req);} catch (Exception e) {ActiveSpan.error(e); // 异常写入 Span 日志throw e;}}这样在 Trace 列表里就能按 model qwen2.5-72b 过滤快速对比不同模型的耗时差异定位是否某个特定模型拖慢了整体。4. 性能剖析 Profile把瓶颈钉到方法级Trace 详情能告诉你「哪个环节慢」但如果慢在 Java 业务自身如 buildPrompt 自身 820ms你还想知道「这 820ms 里具体是哪个方法吃掉的」。这就是性能剖析Profile的用途。SkyWalking 的 Profile 是按需触发的轻量剖析你对某个服务的某个端点创建一条 Profile 任务探针会在一段时间内周期性地采集目标实例的线程栈最后聚合成「方法耗时列表」和「火焰图Flame Graph」。它不需要提前埋点对线上性能影响很小。通过 GraphQL 创建 Profile 任务curl -X POST http://oap:12800/graphql \-H Content-Type: application/json \-d {query: mutation { createProfileTask(input: { serviceId: \llm-inference\, endpointName: \POST:/api/chat\, duration: 10, interval: 10, minDurationThreshold: 1000, maxSamplingCount: 100 }) { id startTime } }}参数含义参数含义建议值---------serviceId目标服务从拓扑节点获取endpointName剖析的端点如 POST:/api/chatduration剖析持续分钟数5~15 分钟interval采样间隔毫秒10~20msminDurationThreshold仅剖析超过该耗时的请求毫秒对齐慢调用阈值maxSamplingCount最大采样数100 左右任务跑完后在 SkyWalking UI 的「Profiling」里查看结果。火焰图中横向宽度代表该方法占用 CPU/时间的比例越宽的栈帧越可能是瓶颈。常见大模型 Java 侧瓶颈巨大的提示词对象被反复 JSON 序列化Jackson 大对象。模板引擎如 FreeMarker / Thymeleaf渲染复杂提示词。同步阻塞的 token 流处理未切异步。锁竞争如共享的 tokenizer 实例。找到宽栈帧后针对性优化缓存序列化结果、异步化、替换锁为 ThreadLocal再用同样的 Profile 任务验证效果形成闭环。5. 连续剖析与最佳实践除按需 Profile 外SkyWalking 9.x 起支持连续性能剖析Continuous Profiling基于 eBPF 持续采集 CPU、网络等系统指标无需手动建任务适合长期观察。但它对内核版本有要求落地前需确认环境支持。把本系列五篇串起来慢调用排查的最佳实践清单**先拓扑后 Trace 再 Profile**拓扑定位节点第 09 篇→ Trace 看环节本文第 2~3 节→ Profile 钉方法本文第 4 节层层下钻。**善用 self/total 区分**self 慢是自身问题total 慢看子 Span。**给 Span 打业务标签**模型名、token 数让过滤和下钻更高效本文第 3 节。**Profile 选对端点与阈值**只剖析慢请求避免噪声duration 别太长以免数据过大。**结合采样与强制采样**保证慢 Trace 不被丢弃第 08 篇否则 Profile 也无从下手。**异步链路先修复**若链路在 CompletableFuture 处断裂第 07 篇Trace 树会缺片段Profile 采样到的线程栈也对不上必须先保证链路连续。6. Trace 标签与日志的进阶用法基础打标签第 3 节已经能帮我们过滤但工程里还有几个进阶技巧值得掌握。**多标签与参数提取**。一个方法往往想记录多个业务维度用 Tags 组合多个 Tag并用 SpEL 从参数里取值无需手写 ActiveSpan.tagTrace(operationName inference.call)Tags({Tag(key model, value arg[0].model),Tag(key promptTokens, value arg[0].promptTokens),Tag(key stream, value arg[0].stream)})public String callInference(ChatRequest req) {return doCall(req);}**结构化日志写入 Span**。除了 tag还可以把关键中间结果以日志形式写进 Span排查时直接在 Trace 详情里展开看到ActiveSpan.info(retrievedDocs docs.size());ActiveSpan.debug(ttftMs ttft);if (ttft SLOW_THRESHOLD) {ActiveSpan.tag(slowFirstToken, true);}**隐私红线**。标签和日志会随 Trace 一起落库千万不要把用户对话原文、手机号、token 等敏感信息写进 tag——既违反合规也会让存储成本飙升。只记录「维度」和「计数」如模型名、token 数、文档条数不记录「内容」。7. 火焰图深度解读与方法级优化闭环火焰图看似复杂记住三条规则就能读**纵向是调用栈深度**从最底下的线程根帧往上每一层是它被谁调用。**横向宽度是「在该栈帧上采样到的比例」**越宽的帧在 CPU/时间上占比越高越该优先优化。**最顶部的边缘帧是「叶子」真正干活的方法**瓶颈几乎总是在某个很宽的叶子帧上。以第 3 节那个 buildPrompt 自身 820ms 为例火焰图把它拆成了「渲染模板 300ms 序列化超大提示词 500ms」。优化动作很明确提示词模板是固定的把渲染结果缓存起来避免每次请求重新渲染超大提示词改用流式写出而非先拼成巨型 String 再序列化。改完后用同样的 Profile 任务再跑一轮火焰图里「序列化超大提示词」那个红框明显变窄总耗时从 820ms 降到 200ms 左右——这就是「剖析 → 优化 → 再剖析验证」的闭环。需要提醒Profile 是采样而非全量计时火焰图宽度是统计近似值个别窄帧的微小差异不必纠结关注「明显最宽的几个帧」即可。8. 连续性能剖析Continuous Profiling实战注意除按需 Profile 外SkyWalking 9.x 起支持连续性能剖析。它基于 eBPF 在内核态持续采集目标实例的 CPUon-CPU / off-CPU、网络等指标无需手动建任务适合长期观察「偶发、说不清什么时候发生」的毛刺。落地注意点**环境要求**需要 Linux 内核 4.x 以上OAP 与探针开启对应模块且探针进程具备 CAP_BPF / CAP_SYS_ADMIN 权限。容器化部署时要给探针容器加相应 capability否则采集不上。**与按需 Profile 互补**按需 Profile 适合「已知某端点慢、定点剖析」连续剖析适合「不知道何时慢、长期监控」。大模型推理偶发的 GPU 等待会让线程 off-CPU让出 CPU 等显存/计算这类「不在 CPU 上跑却很慢」的瓶颈on-CPU 采样看不出off-CPU 的连续剖析反而能抓到。**开销控制**连续剖析持续运行开销高于按需任务建议只在对性能最敏感的核心服务如推理前置、提示词编排开启而非全量铺开。**权限与合规**eBPF 采集的是系统级数据需评估安全合规避免在多租户共享节点上过度采集。把本系列五篇串起来慢调用排查的最佳实践清单**先拓扑后 Trace 再 Profile**拓扑定位节点第 09 篇→ Trace 看环节本文第 2~3 节→ Profile 钉方法本文第 4 节层层下钻。**善用 self/total 区分**self 慢是自身问题total 慢看子 Span。**给 Span 打业务标签**模型名、token 数让过滤和下钻更高效本文第 3、6 节。**Profile 选对端点与阈值**只剖析慢请求避免噪声duration 别太长以免数据过大。**结合采样与强制采样**保证慢 Trace 不被丢弃第 08 篇否则 Profile 也无从下手。**异步链路先修复**若链路在 CompletableFuture 处断裂第 07 篇Trace 树会缺片段Profile 采样到的线程栈也对不上必须先保证链路连续。9. Trace 与日志、指标三位一体可观测性的三大信号是「指标Metrics、链路Traces、日志Logs」SkyWalking 主要覆盖前两者日志由你的日志框架负责而把它们粘起来的就是 TraceId。三者配合的典型排查流**指标先报警**拓扑图/告警发现推理服务 p99 突增Metrics 层。**链路定位环节**下钻慢 Trace确认耗时卡在 POST /v1/chat/completions 这个 Exit SpanTraces 层。**日志看细节**拿 traceId 去日志系统捞出这次请求在推理服务里的完整日志看到具体的 GPU 排队、KV Cache 未命中或超时堆栈Logs 层。缺任何一环都会变慢只有指标没有链路你不知道慢在哪一段只有链路没有日志你不知道那一段内部发生了什么只有日志没有 traceId海量日志里根本捞不出同一次请求。所以前面各篇强调的「链路透传不断」「异步不断」「traceId 进日志第 07 篇 MDC」都是在为这一刻服务。10. 系列速查卡把五篇的核心能力浓缩成一张卡方便贴在工位上篇解决的核心问题核心工具 / 配置---------06 跨进程透传网关到推理服务链路串不起来SW8 头、网关/webflux 插件、sw-python07 异步连续性CompletableFuture / 线程池断链ContextSnapshot、RunnableWrapper、TraceCrossThread08 采样策略高并发下开销与存储成本agent.sample_rate、force_sample_error、slow_trace_segment_threshold、TTL09 拓扑分析不知道瓶颈在哪个节点服务/实例/端点拓扑、百分位、alarm-settings10 Trace 与 Profile不知道瓶颈在哪个方法Trace Span 树 self/total、Profile 火焰图、%tid 日志联动排障口诀可以记成一句话**透传不断链异步不断点采样不漏错拓扑先定位Trace 下钻段Profile 钉方法**。把这六步串成肌肉记忆大模型线上任何性能问题都能在几分钟内有据可依地定位。总结SkyWalking 排查大模型线上性能是一条「全局拓扑 → 慢 Trace 下钻 → 方法级 Profile」的完整链路。前四篇解决了数据「有没有、全不全、省不省、在哪慢」本篇解决「到底哪个方法慢」。掌握这一套你就能把大模型接口的任何性能问题从模糊的「好慢啊」变成精确的「buildPrompt 里 JSON 序列化占了 600ms换成缓存即可」真正用可观测性驱动性能优化。本系列「Java 程序员第 46 阶段大模型调用链路追踪SkyWalking 排查线上性能」到此完结。