【SkyWalking从入门到精通】第18篇：用SkyWalking观察微服务的各个维度：从宏观到微观的侦察术
·
上一篇【第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: Apdex=0.95, P99=200ms, Error=0.1%
# user-service-instance-2: Apdex=0.65, P99=5000ms, Error=5.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慢(P99=3s) ──────────────┐
│ │
│ ┌──→ 影响上游: 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. 找到最慢或出错的Trace
4.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对比：如果P99=200ms，650ms确实是慢请求 │
│ │
│ 第二步：找最长Span │
│ ──→ Span3 MySQL INSERT 100-3000ms │
│ ──→ 占总耗时3000/6500=46% → 这是瓶颈 │
│ │
│ 第三步：看嵌套关系 │
│ ──→ payment-service调用了MySQL │
│ ──→ MySQL Span在payment Span内部 → 是下游依赖 │
│ ──→ 不是payment自身的问题，而是MySQL的问题 │
│ │
│ 第四步：看Span标签 │
│ ──→ 点击MySQL Span查看详情 │
│ ──→ db.statement=INSERT INTO payments... │
│ ──→ db.instance=payment_db │
│ ──→ error=true, error.message="Lock 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变为5000ms（25倍增长）
2. 瓶颈Span从80ms变为4500ms（56倍增长）
3. 瓶颈Span有错误标记（红色）
4. 错误信息明确：Lock wait timeout
5. 观察维度总结
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 | 维度4+5 |
6. 小结
观察微服务就像侦察战场——需要系统的方法和精确的工具：
- 排查SOP：告警 → 全局 → 服务 → 接口 → Trace → 根因，逐层缩小范围
- 指标交叉分析：四大指标不是孤立的，需要组合判断优先级
- 热点识别：流量热点、延迟热点、错误热点，三种热点对应三种优化方向
- 热点传播：沿着调用链往下游走，找最深层的热点才是根因
- Trace四步法：总耗时 → 最长Span → 嵌套关系 → Span标签
下一篇文章，我们将专门讨论关键路径的提取——如何从海量请求中找到影响用户体验最严重的那条路径。
上一篇【第17篇】SkyWalking实战环境搭建：打造你的微服务沙场
下一篇【第19篇】用SkyWalking提取关键路径：找到拖慢全军的瓶颈链路
更多推荐
4
0- 0
已为社区贡献158条内容
所有评论(0)