30秒内通过skywalking拓扑图定位慢调用：先看user/unknown节点异常，再结合cpm、p99、错误率、sla四指标识别瓶颈，最后下钻trace查span耗时、标签和日志，辅以依赖传播分析（含虚线异步链路）精准根因定位。
直接看 SkyWalking 的拓扑图，30 秒内就能圈出慢在哪一跳。
先看拓扑图定位瓶颈节点
拓扑图是所有被追踪服务的自动依赖关系网，不是手动画的，也不用配 XML。SkyWalking OAP 从 Trace 数据里提取「A 调用了 B」的关系聚合成图。大模型或电商类微服务常见结构是：
- USER → 网关 → 业务服务 → 推理服务 / 订单服务
- 业务服务同时调用：向量库、Redis 缓存、外部模型（如 OpenAI）
重点盯两个特殊节点：
- USER 节点：所有入向流量起点，如果它到网关边上的 p99 明显升高，说明问题在入口层（如限流、排队）
- Unknown 节点：某个服务没插探针（比如 Python 推理服务漏装 sw-python），就会显示为灰色 Unknown，这是强信号——链路断了一环，得优先补监控
重点看节点和边上的四个指标
拓扑图的价值不在连线，而在每条边、每个节点旁实时显示的指标：
- CPM（每分钟调用数）：突增常伴随延迟上升，比如缓存击穿后 CPM 暴涨 + p99 飙升
- 响应时间（avg / p50 / p99）：p99 远高于 avg，说明存在长尾请求；若某条边的 p99 达到 2s，而 avg 只有 200ms，大概率是该跳不稳定
- 错误率（Error Rate）：哪怕只有 0.5%，也可能导致上游重试风暴，放大整体延迟
- SLA（成功率）：低于 99.5% 就值得下钻，尤其当它和 p99 同步恶化时，基本可锁定根因
下钻 Trace 找具体慢在哪一行
拓扑图帮你锁定了「推理服务」节点慢，下一步点进去看它的 Trace 列表，按 p99 倒序排列，挑最慢的几条打开：
- 看 Span 树：是不是某个子 Span（比如向量检索、提示词模板渲染）耗时占整条链 80%
- 查标签（Tags）：是否带特定 model_name 或 prompt_type？可快速判断是某类请求专属问题
- 比对日志：用 TraceID 在日志系统里搜，确认是否有 WARN/ERROR（比如 Redis 连接超时、OpenAI 返回 429）
结合依赖分析看故障传播路径
一个服务异常，不只影响自己，还会拖垮上游。拓扑图能反映这种传播：
- 如果「向量库」节点 SLA 下降到 90%，但「业务服务」到它的边错误率飙升、p99 翻倍，说明它正在成为瓶颈出口
- 若「外部模型服务」变成 Unknown 且「业务服务」出向边大量超时，基本可断定是第三方不可用，而非自身代码问题
- 注意虚线边（-.->）：代表异步调用或消息队列，这类链路容易被忽略，但慢消费可能堆积反压，间接拖慢主流程
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
