上一篇【第17篇】SkyWalking实战环境搭建打造你的微服务沙场下一篇【第19篇】用SkyWalking提取关键路径找到拖慢全军的瓶颈链路实战环境搭好了沙场上已经有了5个微服务在运转。但有了作战地图还不够——你得学会侦察术才能从宏观到微观地发现问题、定位问题、解决问题。今天我们就来学习SkyWalking的侦察术——从一张告警通知出发一步步缩小排查范围最终找到问题的精确位置。1. 从业务告警出发的问题排查流程1.1 完整排查SOP当SkyWalking发出告警时你的排查流程应该是这样的——就像侦察兵从情报到行动的标准流程┌──────────────────────────────────────────────────────────────────┐ │ 从告警到根因的标准排查SOP │ │ │ │ ┌─── 步骤1收到告警 ──────────────────────────────┐ │ │ │ 告警: payment-service错误率 5% │ │ │ │ 时间: 14:30 │ │ │ │ 详情: 错误率8.2%, 阈值5% │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ │ 步骤2确认全局影响 │ │ ▼ │ │ ┌─── 步骤2看全局Dashboard ──────────────────────┐ │ │ │ 全局Apdex是否下降 │ │ │ │ 全局错误率是否上升 │ │ │ │ 哪些服务受到影响 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ │ 步骤3定位具体服务 │ │ ▼ │ │ ┌─── 步骤3看服务Dashboard ──────────────────────┐ │ │ │ payment-service的四大指标 │ │ │ │ - Apdex: 0.6 (红灯) │ │ │ │ - P99: 3200ms (非常高) │ │ │ │ - CPM: 80 (正常) │ │ │ │ - Error: 8.2% (超过阈值) │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ │ 步骤4定位具体Endpoint │ │ ▼ │ │ ┌─── 步骤4看Endpoint排行 ──────────────────────┐ │ │ │ /api/pay ──→ 错误率12%, P99 5s │ │ │ │ /api/refund ──→ 错误率0%, P99 200ms │ │ │ │ ──→ 问题在 /api/pay 接口 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ │ 步骤5看Trace链路 │ │ ▼ │ │ ┌─── 步骤5看Trace瀑布图 ──────────────────────┐ │ │ │ /api/pay的Trace: │ │ │ │ Span1: gateway 0-5000ms │ │ │ │ Span2: payment-service 50-5000ms │ │ │ │ Span3: MySQL INSERT 100-3000ms ← 这里报错 │ │ │ │ ──→ MySQL写入超时导致支付失败 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ │ 步骤6根因确认 │ │ ▼ │ │ ┌─── 步骤6根因分析 ────────────────────────────┐ │ │ │ MySQL INSERT支付记录超时 │ │ │ │ 可能原因 │ │ │ │ 1. 数据库锁等待 │ │ │ │ 2. 连接池耗尽 │ │ │ │ 3. 表数据量过大 │ │ │ │ ──→ 查MySQL监控确认具体原因 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ 排查路线告警 → 全局 → 服务 → 接口 → Trace → 根因 │ │ 每一步都在缩小范围直到找到精确的故障点 │ └───────────────────────────────────────────────────────────────────┘这个SOP的核心原则是逐层缩小范围——从全局到局部从宏观到微观从粗粒度到细粒度。就像侦察兵先用卫星地图看到城市再用望远镜看到街道最后用显微镜看到具体的弹孔。2. 服务维度指标解读2.1 四大指标的交叉分析单独看一个指标意义有限——就像只看伤亡率不知道战争规模只看车流量不知道拥堵程度。四大指标需要交叉分析┌──────────────────────────────────────────────────────────────────┐ │ 四大指标交叉分析矩阵 │ │ │ │ │ Apdex高 │ Apdex低 │ │ ─────────┼─────────┼────────── │ │ CPM高 │ 健康热门 │ 热门但体验差 │ │ (流量大) │ (正常) │ (重点关注) │ │ ─────────┼─────────┼────────── │ │ CPM低 │ 健康冷门 │ 冷门且体验差 │ │ (流量小) │ (正常) │ (可能废弃) │ │ │ │ │ Error低 │ Error高 │ │ ─────────┼─────────┼────────── │ │ P99低 │ 完美 │ 快但出错 │ │ (响应快) │ (理想) │ (可能是逻辑错误) │ │ ─────────┼─────────┼────────── │ │ P99高 │ 慢但稳定 │ 慢且出错 │ │ (响应慢) │ (需优化) │ (紧急处理) │ │ │ │ 优先级 │ │ 慢且出错 → 最高优先级立即处理 │ │ 快但出错 → 高优先级逻辑问题 │ │ 热门但体验差 → 中优先级性能优化 │ │ 慢但稳定 → 低优先级计划优化 │ │ ⚪ 完美 → 不需要处理 │ └──────────────────────────────────────────────────────────────────┘2.2 服务实例维度的观察同一服务的不同实例可能有不同表现——就像同一部队的不同连队有的伤亡大有的伤亡小# 在Service Dashboard中选择Instances标签# 可以看到每个实例的独立指标# 实例对比示例# user-service-instance-1: Apdex0.95, P99200ms, Error0.1%# user-service-instance-2: Apdex0.65, P995000ms, Error5.2%# ──→ instance-2有问题可能资源不足或配置异常实例差异的常见原因原因表现排查方向CPU资源不足P99高但Error低查K8s的CPU limits内存不足Error高OOM查JVM内存和GC数据库连接池耗尽Error高P99高查连接池配置网络分区部分实例Error高查网络连通性配置不一致实例指标差异大查配置是否统一2.3 时间维度的趋势分析指标不是孤立的数据点——它们是时间序列。看趋势比看当前值更重要# 在Dashboard中选择时间范围观察趋势# 良好的趋势指标平稳波动小# ┌──────────────────────────────────────┐# │ P99 ────────────────── (平稳线) │# └──────────────────────────────────────┘# 异常的趋势指标突然飙升# ┌──────────────────────────────────────┐# │ P99 ───────/\/\/\/─── (突然飙升) │# └──────────────────────────────────────┘# 退化趋势指标缓慢上升# ┌──────────────────────────────────────┐# │ P99 ──────/────────── (缓慢退化) │# └──────────────────────────────────────┘三种趋势类型突变型指标突然飙升——通常由代码变更、配置变更或外部故障引起退化型指标缓慢上升——通常由数据量增长、资源消耗累积引起周期型指标有规律地波动——通常与业务周期相关如高峰/低谷3. 拓扑图中识别服务热点3.1 什么是服务热点服务热点就是系统中被大量调用或延迟严重的节点——就像交通地图上的堵车路段。识别热点是优化的第一步。3.2 拓扑图中的三种热点┌──────────────────────────────────────────────────────────────────┐ │ 拓扑图中的三种热点类型 │ │ │ │ 类型一流量热点 │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ user-service ──→ order-service ──→ payment-service │ │ │ │ CPM:500 CPM:450 CPM:400 │ │ │ │ ──→ order-service是流量汇聚点 │ │ │ │ 所有下游请求都经过它 │ │ │ │ 优化策略增加order-service实例 │ │ │ └───────────────────────────────────────────────────────┘ │ │ │ │ 类型二延迟热点 │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ user-service ──→ order-service ──→ payment-service │ │ │ │ P99:50ms P99:3s!! P99:200ms │ │ │ │ ──→ order-service是延迟瓶颈 │ │ │ │ 它的P99远高于上下游 │ │ │ │ 优化策略优化order-service内部逻辑 │ │ │ └───────────────────────────────────────────────────────┘ │ │ │ │ 类型三错误热点 │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ user-service ──→ order-service ──→ payment-service │ │ │ │ Error:0.1% Error:0.2% Error:8%!! │ │ │ │ ──→ payment-service是错误源头 │ │ │ │ 它的错误率远高于其他服务 │ │ │ │ 优化策略修复payment-service的bug │ │ │ └───────────────────────────────────────────────────────┘ │ │ │ │ 识别方法 │ │ 1. 找CPM最高的链路 → 流量热点 │ │ 2. 找P99最高的节点 → 延迟热点 │ │ 3. 找Error最高的节点 → 错误热点 │ │ 4. 三者交叉的节点 → 系统的最大痛点 │ └──────────────────────────────────────────────────────────────────┘3.3 热点传播路径热点不是孤立的——它会沿着调用链传播。就像堵车会从一条路蔓延到周围的路段┌─ payment-service慢(P993s) ──────────────┐ │ │ │ ┌──→ 影响上游: order-service慢 │ │ │ order等待payment返回 → order也变慢 │ │ │ │ │ ├──→ 影响更上游: user-service慢 │ │ │ user等待order返回 → user也变慢 │ │ │ │ │ └──→ 影响网关: gateway慢 │ │ gateway等待user返回 → 整体变慢 │ │ │ │ 排查原则找最下游的热点 │ │ 热点的根源通常在最底层 │ └────────────────────────────────────────────┘排查原则沿着调用链往下游走找到最深层的热点节点——那里才是真正的根因。4. 结合Trace定位具体请求4.1 从指标到Trace的跳转SkyWalking UI的设计让从指标到Trace的跳转非常顺畅# 从Service Dashboard跳转到Trace# 步骤# 1. 选择有问题的服务如payment-service# 2. 在左侧面板选择Trace标签# 3. 筛选条件自动设为该服务的Trace# 4. 选择错误Trace或慢Trace# 从Endpoint排行跳转到Trace# 步骤# 1. 在Endpoint排行中选择慢Endpoint# 2. 点击Trace链接# 3. 自动筛选该Endpoint的Trace# 4. 找到最慢或出错的Trace4.2 Trace筛选技巧# 按条件筛选Trace# 找错误Trace# Trace列表 → 状态Error → 查看错误详情# 找慢Trace# Trace列表 → 响应时间1000ms → 查看慢请求# 找特定服务的Trace# Trace列表 → 服务名payment-service# 找特定Endpoint的Trace# Trace列表 → Endpoint/api/pay# 按时间范围筛选# Trace列表 → 时间范围告警时间段4.3 Trace分析的核心方法找到目标Trace后分析步骤┌──────────────────────────────────────────────────────────────────┐ │ Trace分析四步法 │ │ │ │ 第一步看总耗时 │ │ ──→ Trace总耗时650ms → 算不算慢 │ │ ──→ 与P99对比如果P99200ms650ms确实是慢请求 │ │ │ │ 第二步找最长Span │ │ ──→ Span3 MySQL INSERT 100-3000ms │ │ ──→ 占总耗时3000/650046% → 这是瓶颈 │ │ │ │ 第三步看嵌套关系 │ │ ──→ payment-service调用了MySQL │ │ ──→ MySQL Span在payment Span内部 → 是下游依赖 │ │ ──→ 不是payment自身的问题而是MySQL的问题 │ │ │ │ 第四步看Span标签 │ │ ──→ 点击MySQL Span查看详情 │ │ ──→ db.statementINSERT INTO payments... │ │ ──→ db.instancepayment_db │ │ ──→ errortrue, error.messageLock wait timeout │ │ ──→ ──→ 根因MySQL锁等待超时 │ │ │ │ 总结总耗时→找最长Span→看嵌套→看标签→根因 │ └──────────────────────────────────────────────────────────────────┘4.4 正常Trace vs 异常Trace对比正常和异常的Trace差异一目了然正常Trace: ┌─ gateway 0-200ms ──────────────────────────────────────┐ │ ┌─ user-service 10-180ms ────────────────────┐ │ │ │ ┌─ MySQL SELECT 20-80ms ─────────┐ │ │ │ │ └─────────────────────────────────┘ │ │ │ └────────────────────────────────────┘ │ │ └───────────────────────────────────────────────┘ 异常Trace: ┌─ gateway 0-5000ms ────────────────────────────────────┐ │ ┌─ payment-service 50-5000ms ───────────┐ │ │ │ ┌─ MySQL INSERT 100-4500ms [ERROR] ──┐ │ │ │ │ Lock wait timeout exceeded │ │ │ │ └────────────────────────────────────┘ │ │ └───────────────────────────────────────┘ │ └───────────────────────────────────────────────────────┘ 对比发现 1. 总耗时从200ms变为5000ms25倍增长 2. 瓶颈Span从80ms变为4500ms56倍增长 3. 瓶颈Span有错误标记红色 4. 错误信息明确Lock wait timeout5. 观察维度总结5.1 五个观察维度SkyWalking提供了从宏观到微观的五个观察维度┌──────────────────────────────────────────────────────────────────┐ │ SkyWalking五个观察维度 │ │ │ │ ┌─── 维度1全局视角 ──────────────────────────────┐ │ │ │ 观察对象整个系统的健康度 │ │ │ │ 核心指标全局Apdex/全局错误率 │ │ │ │ 解读方式看是否有人受伤 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─── 维度2服务视角 ──────────────────────────────┐ │ │ │ 观察对象单个服务的四大指标 │ │ │ │ 核心指标Apdex/P99/CPM/Error │ │ │ │ 解读方式哪个部队伤亡率最高 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─── 维度3拓扑视角 ──────────────────────────────┐ │ │ │ 观察对象服务间调用关系和热点 │ │ │ │ 核心指标链路CPM/P99/Error │ │ │ │ 解读方式哪条运输线堵车最严重 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─── 维度4接口视角 ──────────────────────────────┐ │ │ │ 观察对象单个API的性能 │ │ │ │ 核心指标Endpoint P99/CPM/Error │ │ │ │ 解读方式哪条路上车最多最堵 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─── 维度5链路视角 ──────────────────────────────┐ │ │ │ 观察对象单次请求的完整调用链 │ │ │ │ 核心数据Span瀑布图/标签/错误信息 │ │ │ │ 解读方式这辆车到底在哪个路口堵了 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ 从维度1到维度5范围越来越小信息越来越精确 │ │ 问题排查就是沿着这5个维度逐层深入 │ └──────────────────────────────────────────────────────────────────┘5.2 观察的节奏持续观察不是一次性的动作——需要建立日常巡检的节奏时间动作维度每天早上看全局Dashboard维度1每天中午检查告警面板维度2每周一次分析拓扑热点维度3有告警时定位接口和Trace维度456. 小结观察微服务就像侦察战场——需要系统的方法和精确的工具排查SOP告警 → 全局 → 服务 → 接口 → Trace → 根因逐层缩小范围指标交叉分析四大指标不是孤立的需要组合判断优先级热点识别流量热点、延迟热点、错误热点三种热点对应三种优化方向热点传播沿着调用链往下游走找最深层的热点才是根因Trace四步法总耗时 → 最长Span → 嵌套关系 → Span标签下一篇文章我们将专门讨论关键路径的提取——如何从海量请求中找到影响用户体验最严重的那条路径。上一篇【第17篇】SkyWalking实战环境搭建打造你的微服务沙场下一篇【第19篇】用SkyWalking提取关键路径找到拖慢全军的瓶颈链路
【SkyWalking从入门到精通】第18篇：用SkyWalking观察微服务的各个维度：从宏观到微观的侦察术
发布时间：2026/7/8 14:40:03
上一篇【第17篇】SkyWalking实战环境搭建打造你的微服务沙场下一篇【第19篇】用SkyWalking提取关键路径找到拖慢全军的瓶颈链路实战环境搭好了沙场上已经有了5个微服务在运转。但有了作战地图还不够——你得学会侦察术才能从宏观到微观地发现问题、定位问题、解决问题。今天我们就来学习SkyWalking的侦察术——从一张告警通知出发一步步缩小排查范围最终找到问题的精确位置。1. 从业务告警出发的问题排查流程1.1 完整排查SOP当SkyWalking发出告警时你的排查流程应该是这样的——就像侦察兵从情报到行动的标准流程┌──────────────────────────────────────────────────────────────────┐ │ 从告警到根因的标准排查SOP │ │ │ │ ┌─── 步骤1收到告警 ──────────────────────────────┐ │ │ │ 告警: payment-service错误率 5% │ │ │ │ 时间: 14:30 │ │ │ │ 详情: 错误率8.2%, 阈值5% │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ │ 步骤2确认全局影响 │ │ ▼ │ │ ┌─── 步骤2看全局Dashboard ──────────────────────┐ │ │ │ 全局Apdex是否下降 │ │ │ │ 全局错误率是否上升 │ │ │ │ 哪些服务受到影响 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ │ 步骤3定位具体服务 │ │ ▼ │ │ ┌─── 步骤3看服务Dashboard ──────────────────────┐ │ │ │ payment-service的四大指标 │ │ │ │ - Apdex: 0.6 (红灯) │ │ │ │ - P99: 3200ms (非常高) │ │ │ │ - CPM: 80 (正常) │ │ │ │ - Error: 8.2% (超过阈值) │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ │ 步骤4定位具体Endpoint │ │ ▼ │ │ ┌─── 步骤4看Endpoint排行 ──────────────────────┐ │ │ │ /api/pay ──→ 错误率12%, P99 5s │ │ │ │ /api/refund ──→ 错误率0%, P99 200ms │ │ │ │ ──→ 问题在 /api/pay 接口 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ │ 步骤5看Trace链路 │ │ ▼ │ │ ┌─── 步骤5看Trace瀑布图 ──────────────────────┐ │ │ │ /api/pay的Trace: │ │ │ │ Span1: gateway 0-5000ms │ │ │ │ Span2: payment-service 50-5000ms │ │ │ │ Span3: MySQL INSERT 100-3000ms ← 这里报错 │ │ │ │ ──→ MySQL写入超时导致支付失败 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ │ 步骤6根因确认 │ │ ▼ │ │ ┌─── 步骤6根因分析 ────────────────────────────┐ │ │ │ MySQL INSERT支付记录超时 │ │ │ │ 可能原因 │ │ │ │ 1. 数据库锁等待 │ │ │ │ 2. 连接池耗尽 │ │ │ │ 3. 表数据量过大 │ │ │ │ ──→ 查MySQL监控确认具体原因 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ 排查路线告警 → 全局 → 服务 → 接口 → Trace → 根因 │ │ 每一步都在缩小范围直到找到精确的故障点 │ └───────────────────────────────────────────────────────────────────┘这个SOP的核心原则是逐层缩小范围——从全局到局部从宏观到微观从粗粒度到细粒度。就像侦察兵先用卫星地图看到城市再用望远镜看到街道最后用显微镜看到具体的弹孔。2. 服务维度指标解读2.1 四大指标的交叉分析单独看一个指标意义有限——就像只看伤亡率不知道战争规模只看车流量不知道拥堵程度。四大指标需要交叉分析┌──────────────────────────────────────────────────────────────────┐ │ 四大指标交叉分析矩阵 │ │ │ │ │ Apdex高 │ Apdex低 │ │ ─────────┼─────────┼────────── │ │ CPM高 │ 健康热门 │ 热门但体验差 │ │ (流量大) │ (正常) │ (重点关注) │ │ ─────────┼─────────┼────────── │ │ CPM低 │ 健康冷门 │ 冷门且体验差 │ │ (流量小) │ (正常) │ (可能废弃) │ │ │ │ │ Error低 │ Error高 │ │ ─────────┼─────────┼────────── │ │ P99低 │ 完美 │ 快但出错 │ │ (响应快) │ (理想) │ (可能是逻辑错误) │ │ ─────────┼─────────┼────────── │ │ P99高 │ 慢但稳定 │ 慢且出错 │ │ (响应慢) │ (需优化) │ (紧急处理) │ │ │ │ 优先级 │ │ 慢且出错 → 最高优先级立即处理 │ │ 快但出错 → 高优先级逻辑问题 │ │ 热门但体验差 → 中优先级性能优化 │ │ 慢但稳定 → 低优先级计划优化 │ │ ⚪ 完美 → 不需要处理 │ └──────────────────────────────────────────────────────────────────┘2.2 服务实例维度的观察同一服务的不同实例可能有不同表现——就像同一部队的不同连队有的伤亡大有的伤亡小# 在Service Dashboard中选择Instances标签# 可以看到每个实例的独立指标# 实例对比示例# user-service-instance-1: Apdex0.95, P99200ms, Error0.1%# user-service-instance-2: Apdex0.65, P995000ms, Error5.2%# ──→ instance-2有问题可能资源不足或配置异常实例差异的常见原因原因表现排查方向CPU资源不足P99高但Error低查K8s的CPU limits内存不足Error高OOM查JVM内存和GC数据库连接池耗尽Error高P99高查连接池配置网络分区部分实例Error高查网络连通性配置不一致实例指标差异大查配置是否统一2.3 时间维度的趋势分析指标不是孤立的数据点——它们是时间序列。看趋势比看当前值更重要# 在Dashboard中选择时间范围观察趋势# 良好的趋势指标平稳波动小# ┌──────────────────────────────────────┐# │ P99 ────────────────── (平稳线) │# └──────────────────────────────────────┘# 异常的趋势指标突然飙升# ┌──────────────────────────────────────┐# │ P99 ───────/\/\/\/─── (突然飙升) │# └──────────────────────────────────────┘# 退化趋势指标缓慢上升# ┌──────────────────────────────────────┐# │ P99 ──────/────────── (缓慢退化) │# └──────────────────────────────────────┘三种趋势类型突变型指标突然飙升——通常由代码变更、配置变更或外部故障引起退化型指标缓慢上升——通常由数据量增长、资源消耗累积引起周期型指标有规律地波动——通常与业务周期相关如高峰/低谷3. 拓扑图中识别服务热点3.1 什么是服务热点服务热点就是系统中被大量调用或延迟严重的节点——就像交通地图上的堵车路段。识别热点是优化的第一步。3.2 拓扑图中的三种热点┌──────────────────────────────────────────────────────────────────┐ │ 拓扑图中的三种热点类型 │ │ │ │ 类型一流量热点 │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ user-service ──→ order-service ──→ payment-service │ │ │ │ CPM:500 CPM:450 CPM:400 │ │ │ │ ──→ order-service是流量汇聚点 │ │ │ │ 所有下游请求都经过它 │ │ │ │ 优化策略增加order-service实例 │ │ │ └───────────────────────────────────────────────────────┘ │ │ │ │ 类型二延迟热点 │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ user-service ──→ order-service ──→ payment-service │ │ │ │ P99:50ms P99:3s!! P99:200ms │ │ │ │ ──→ order-service是延迟瓶颈 │ │ │ │ 它的P99远高于上下游 │ │ │ │ 优化策略优化order-service内部逻辑 │ │ │ └───────────────────────────────────────────────────────┘ │ │ │ │ 类型三错误热点 │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ user-service ──→ order-service ──→ payment-service │ │ │ │ Error:0.1% Error:0.2% Error:8%!! │ │ │ │ ──→ payment-service是错误源头 │ │ │ │ 它的错误率远高于其他服务 │ │ │ │ 优化策略修复payment-service的bug │ │ │ └───────────────────────────────────────────────────────┘ │ │ │ │ 识别方法 │ │ 1. 找CPM最高的链路 → 流量热点 │ │ 2. 找P99最高的节点 → 延迟热点 │ │ 3. 找Error最高的节点 → 错误热点 │ │ 4. 三者交叉的节点 → 系统的最大痛点 │ └──────────────────────────────────────────────────────────────────┘3.3 热点传播路径热点不是孤立的——它会沿着调用链传播。就像堵车会从一条路蔓延到周围的路段┌─ payment-service慢(P993s) ──────────────┐ │ │ │ ┌──→ 影响上游: order-service慢 │ │ │ order等待payment返回 → order也变慢 │ │ │ │ │ ├──→ 影响更上游: user-service慢 │ │ │ user等待order返回 → user也变慢 │ │ │ │ │ └──→ 影响网关: gateway慢 │ │ gateway等待user返回 → 整体变慢 │ │ │ │ 排查原则找最下游的热点 │ │ 热点的根源通常在最底层 │ └────────────────────────────────────────────┘排查原则沿着调用链往下游走找到最深层的热点节点——那里才是真正的根因。4. 结合Trace定位具体请求4.1 从指标到Trace的跳转SkyWalking UI的设计让从指标到Trace的跳转非常顺畅# 从Service Dashboard跳转到Trace# 步骤# 1. 选择有问题的服务如payment-service# 2. 在左侧面板选择Trace标签# 3. 筛选条件自动设为该服务的Trace# 4. 选择错误Trace或慢Trace# 从Endpoint排行跳转到Trace# 步骤# 1. 在Endpoint排行中选择慢Endpoint# 2. 点击Trace链接# 3. 自动筛选该Endpoint的Trace# 4. 找到最慢或出错的Trace4.2 Trace筛选技巧# 按条件筛选Trace# 找错误Trace# Trace列表 → 状态Error → 查看错误详情# 找慢Trace# Trace列表 → 响应时间1000ms → 查看慢请求# 找特定服务的Trace# Trace列表 → 服务名payment-service# 找特定Endpoint的Trace# Trace列表 → Endpoint/api/pay# 按时间范围筛选# Trace列表 → 时间范围告警时间段4.3 Trace分析的核心方法找到目标Trace后分析步骤┌──────────────────────────────────────────────────────────────────┐ │ Trace分析四步法 │ │ │ │ 第一步看总耗时 │ │ ──→ Trace总耗时650ms → 算不算慢 │ │ ──→ 与P99对比如果P99200ms650ms确实是慢请求 │ │ │ │ 第二步找最长Span │ │ ──→ Span3 MySQL INSERT 100-3000ms │ │ ──→ 占总耗时3000/650046% → 这是瓶颈 │ │ │ │ 第三步看嵌套关系 │ │ ──→ payment-service调用了MySQL │ │ ──→ MySQL Span在payment Span内部 → 是下游依赖 │ │ ──→ 不是payment自身的问题而是MySQL的问题 │ │ │ │ 第四步看Span标签 │ │ ──→ 点击MySQL Span查看详情 │ │ ──→ db.statementINSERT INTO payments... │ │ ──→ db.instancepayment_db │ │ ──→ errortrue, error.messageLock wait timeout │ │ ──→ ──→ 根因MySQL锁等待超时 │ │ │ │ 总结总耗时→找最长Span→看嵌套→看标签→根因 │ └──────────────────────────────────────────────────────────────────┘4.4 正常Trace vs 异常Trace对比正常和异常的Trace差异一目了然正常Trace: ┌─ gateway 0-200ms ──────────────────────────────────────┐ │ ┌─ user-service 10-180ms ────────────────────┐ │ │ │ ┌─ MySQL SELECT 20-80ms ─────────┐ │ │ │ │ └─────────────────────────────────┘ │ │ │ └────────────────────────────────────┘ │ │ └───────────────────────────────────────────────┘ 异常Trace: ┌─ gateway 0-5000ms ────────────────────────────────────┐ │ ┌─ payment-service 50-5000ms ───────────┐ │ │ │ ┌─ MySQL INSERT 100-4500ms [ERROR] ──┐ │ │ │ │ Lock wait timeout exceeded │ │ │ │ └────────────────────────────────────┘ │ │ └───────────────────────────────────────┘ │ └───────────────────────────────────────────────────────┘ 对比发现 1. 总耗时从200ms变为5000ms25倍增长 2. 瓶颈Span从80ms变为4500ms56倍增长 3. 瓶颈Span有错误标记红色 4. 错误信息明确Lock wait timeout5. 观察维度总结5.1 五个观察维度SkyWalking提供了从宏观到微观的五个观察维度┌──────────────────────────────────────────────────────────────────┐ │ SkyWalking五个观察维度 │ │ │ │ ┌─── 维度1全局视角 ──────────────────────────────┐ │ │ │ 观察对象整个系统的健康度 │ │ │ │ 核心指标全局Apdex/全局错误率 │ │ │ │ 解读方式看是否有人受伤 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─── 维度2服务视角 ──────────────────────────────┐ │ │ │ 观察对象单个服务的四大指标 │ │ │ │ 核心指标Apdex/P99/CPM/Error │ │ │ │ 解读方式哪个部队伤亡率最高 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─── 维度3拓扑视角 ──────────────────────────────┐ │ │ │ 观察对象服务间调用关系和热点 │ │ │ │ 核心指标链路CPM/P99/Error │ │ │ │ 解读方式哪条运输线堵车最严重 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─── 维度4接口视角 ──────────────────────────────┐ │ │ │ 观察对象单个API的性能 │ │ │ │ 核心指标Endpoint P99/CPM/Error │ │ │ │ 解读方式哪条路上车最多最堵 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─── 维度5链路视角 ──────────────────────────────┐ │ │ │ 观察对象单次请求的完整调用链 │ │ │ │ 核心数据Span瀑布图/标签/错误信息 │ │ │ │ 解读方式这辆车到底在哪个路口堵了 │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ 从维度1到维度5范围越来越小信息越来越精确 │ │ 问题排查就是沿着这5个维度逐层深入 │ └──────────────────────────────────────────────────────────────────┘5.2 观察的节奏持续观察不是一次性的动作——需要建立日常巡检的节奏时间动作维度每天早上看全局Dashboard维度1每天中午检查告警面板维度2每周一次分析拓扑热点维度3有告警时定位接口和Trace维度456. 小结观察微服务就像侦察战场——需要系统的方法和精确的工具排查SOP告警 → 全局 → 服务 → 接口 → Trace → 根因逐层缩小范围指标交叉分析四大指标不是孤立的需要组合判断优先级热点识别流量热点、延迟热点、错误热点三种热点对应三种优化方向热点传播沿着调用链往下游走找最深层的热点才是根因Trace四步法总耗时 → 最长Span → 嵌套关系 → Span标签下一篇文章我们将专门讨论关键路径的提取——如何从海量请求中找到影响用户体验最严重的那条路径。上一篇【第17篇】SkyWalking实战环境搭建打造你的微服务沙场下一篇【第19篇】用SkyWalking提取关键路径找到拖慢全军的瓶颈链路
