为什么需要链路追踪可观测性三大支柱大模型调用的链路追踪特殊性SkyWalking 在可观测体系中的定位全栈可观测性体系搭建路线小结与本阶段路线图1. 为什么需要链路追踪当系统从单体应用演进为微服务再进一步叠加大模型LLM调用后一次用户请求往往要穿越几十个服务节点其中还可能包含一次动辄数秒、甚至数十秒的大模型推理调用。传统看日志、查数据库的排障方式在这种长链路、异构调用面前几乎失效。链路追踪Distributed Tracing正是为了在分布式系统中还原一次请求完整路径而生的技术。1.1 微服务架构下的黑盒困境在单体时代一次请求的处理逻辑集中在一个进程里出现问题直接打堆栈即可定位。微服务化之后请求被拆散到多个进程、甚至跨语言的服务中网关把请求转发给 order-serviceorder-service 调用 user-service 和 inventory-serviceinventory-service 又依赖 redis 与 mysql当 order-service 响应变慢你很难只凭它自己的日志判断是下游 user-service 慢了还是数据库锁等待还是自身线程池被打满每个服务都只看到自己这一段整条链路的全局视图是缺失的。1.2 大模型调用带来的新复杂度引入大模型后问题被进一步放大**耗时数量级跃升**传统 RPC 调用通常在毫秒到几百毫秒而大模型推理常在 1~30 秒流式streaming响应更是以分钟计。**异构链路段**一次问答可能涉及「应用网关 → 业务服务 → 向量数据库检索RAG→ 大模型网关 → 远端 LLM API」每一段的技术栈和时延特征都不同。**成本维度**除了时延Token 消耗也是关键指标需要把花了多少钱关联到具体调用链路。1.3 一个真实的线上性能故障场景某天凌晨告警智能客服对话接口 P99 从 800ms 涨到 12s。值班同学翻遍日志发现应用本身 CPU 正常、GC 正常。最终通过链路追踪平台看到故障根因不在业务代码而在 vector-search-service 的一次慢查询向量索引未命中退化成全表扫描把 RAG 检索时延从 50ms 拉到了 9s进而阻塞了整条对话链路。如果没有链路追踪这个根因可能要花数小时才能定位。这正是链路追踪的价值**把黑盒变成透明管道让每一毫秒的耗时都有归属。**2. 可观测性三大支柱业界公认的可观测性Observability由三大支柱构成Metrics指标、Tracing链路、Logging日志。三者互补缺一不可。2.1 Metrics 指标指标是聚合后的数值回答系统整体健康吗。例如 QPS、错误率、P99 时延、JVM 堆内存使用率。指标的优势是开销低、适合长期存储与告警劣势是**丢失了单次请求的细节**无法告诉你这一次慢请求到底卡在哪。2.2 Tracing 链路链路追踪记录单次请求穿越所有服务的完整路径由一个 Trace 和若干 Span 组成。它回答这一次请求慢在哪里。这是本系列的核心主题SkyWalking 正是以 Tracing 为主、兼顾 Metrics 的平台。2.3 Logging 日志日志是离散的文本事件回答当时发生了什么。结构化日志配合 TraceId 关联后可以从某条慢链路直接跳转到对应的错误日志。2.4 三者如何协同三者并非替代关系而是协同关系关键是**通过统一的上下文TraceId打通**支柱回答的问题典型工具数据量级关联键---------------Metrics系统整体是否健康Prometheus、Grafana低聚合指标标签Tracing单次请求慢在哪里SkyWalking、Jaeger中TraceIdLogging具体发生了什么ELK、Loki高明细TraceId 实践建议用 Metrics 发现异常告警用 Tracing 定位瓶颈下钻用 Logging 确认根因取证。三者的桥接点是 TraceId。3. 大模型调用的链路追踪特殊性大模型链路和传统微服务链路有本质差异直接套用传统埋点方案会漏掉最贵、最慢的那一段。3.1 长耗时与流式响应传统 Tracer 的 Span 通常在请求返回时结束。但大模型流式响应会先返回若干 token再持续推送。如果不做特殊建模整条链路会被统计为一个超长 Span无法区分首字时延TTFT和完整生成时延TPOT。SkyWalking 的 Span 可以分阶段打点把等待首 token和流式输出拆成不同区间。3.2 多段调用链一次 RAG 问答的典型链路如下见图 figure_01_2用户请求└─ API Gateway└─ Chat Service├─ Vector DB (RAG 检索) ← 网络 向量计算├─ Prompt 组装 (Local Span)└─ LLM Gateway└─ 远端大模型 API ← 最慢、最贵的一段每一段都要被纳入同一个 Trace否则排障时就会在业务服务和大模型之间出现断点。3.3 Token 成本与链路关联大模型调用会产生 Token 消耗与费用。最佳实践是在 Exit Span向 LLM 发起调用的 Span上挂载 Tagtags:- llm.model: gpt-4o- llm.token.prompt: 1280- llm.token.completion: 540- llm.cost.usd: 0.021- llm.ttft.ms: 860 # 首字时延这样就能在 SkyWalking 的拓扑图与追踪详情里直接看到哪次调用最贵、哪次调用最慢。4. SkyWalking 在可观测体系中的定位4.1 为什么选 SkyWalking对比主流方案维度SkyWalkingJaegerZipkin------------语言生态多语言Java 最强多语言偏 Java部署复杂度中等OAP 存储中需配后端低服务拓扑原生强大弱弱告警能力内置需外部需外部大模型适配插件可扩展需自研需自研对 Java 微服务 大模型场景SkyWalking 的**无侵入 Agent 埋点**和**原生拓扑图**最具吸引力无需改业务代码即可拿到全链路视图。4.2 SkyWalking 能力矩阵SkyWalking 提供的能力覆盖三大支柱中的两块Tracing Metrics并可通过日志插件桥接 Logging**拓扑自动发现**从链路数据自动绘制服务依赖图。**分布式追踪**还原每一次请求的完整 Span 树。**性能剖析Profiling**线程级 CPU/栈火焰图定位代码热点。**告警**基于 OALObservability Analysis Language定义规则。**可观测性分析语言 OAL**用类 SQL 语法自定义指标。5. 全栈可观测性体系搭建路线5.1 技术选型建议observability_stack:tracing: skywalking # 分布式追踪 拓扑 性能剖析metrics: prometheusgrafana # 指标采集与看板logging: lokielk # 日志按 TraceId 关联bridge:- skywalking-log - loki # 日志带 TraceId- grafana - skywalking # 看板跳转追踪5.2 分阶段实施路线**阶段一接入 SkyWalking Agent**先拿到拓扑与基础 Trace零侵入。**阶段二补充大模型 Span 埋点**手动埋点 自定义 Tag覆盖 LLM 调用段。**阶段三打通日志与指标**让 TraceId 贯穿 Metrics/Logging。**阶段四建立告警与性能剖析机制**实现异常自动下钻。6. 小结与本阶段路线图本篇我们建立了全局认知链路追踪是分布式系统中还原请求路径的核心手段可观测性由 Metrics、Tracing、Logging 三大支柱构成大模型调用因其长耗时、多段、高成本的特性对链路追踪提出了新要求而 SkyWalking 凭借无侵入 Agent 与原生拓扑是 Java 微服务接入大模型场景下的优选。接下来的路线图第 02 篇剖析 SkyWalking 四大组件Agent / OAP / Storage / UI内部机制。第 03 篇深入 Java Agent 字节码增强原理。第 04 篇Spring Boot 接入 SkyWalking 实战。第 05 篇大模型链路的 Trace/Span 建模与 Tag 规范。 一句话总结**可观测性不是装个工具而是一套贯穿 Metrics、Tracing、Logging 的方法论链路追踪是这套方法论里让慢请求无所遁形的那把钥匙。**