【SkyWalking从入门到精通】第16篇：SkyWalking UI使用手册：学会阅读指挥中心的作战地图-拓冰建站

上一篇【第15篇】SkyWalking存储选型指南：为档案馆挑选最佳建材
下一篇【第17篇】SkyWalking实战环境搭建：打造你的微服务沙场

指挥中心建好了，档案馆也选好了建材，接下来最激动人心的时刻——打开作战地图，看看你的微服务帝国到底是什么样子。

SkyWalking UI就是这份作战地图。它把OAP Server分析出来的海量数据，变成直观的图表、拓扑和瀑布图。但如果你不会读这份地图，就像拿着GPS却不知道东南西北——地图再好看也没用。

今天我们就来学习如何阅读这份作战地图。

1. Dashboard核心指标

1.1 Dashboard的整体结构

SkyWalking UI的Dashboard分为几个层级——从全局到局部，从宏观到微观：

┌──────────────────────────────────────────────────────────────────┐ │ SkyWalking UI Dashboard层级结构 │ │ │ │ ┌─── Global Dashboard ───┐ 全局视角：所有服务的总览 │ │ │ - 全局Apdex │ │ │ │ - 全局响应时间 │ │ │ │ - 全局吞吐量 │ │ │ │ - 全局错误率 │ │ │ └─────────────────────────┘ │ │ │ │ │ │ 选择某个服务 │ │ ▼ │ │ ┌─── Service Dashboard ──┐ 服务视角：单个服务的详情 │ │ │ - 服务Apdex │ │ │ │ - 服务响应时间 │ │ │ │ - 服务吞吐量 │ │ │ │ - 服务错误率 │ │ │ │ - 服务拓扑图 │ │ │ └─────────────────────────┘ │ │ │ │ │ │ 选择某个Endpoint │ │ ▼ │ │ ┌─── Endpoint Dashboard ─┐ 接口视角：单个API的详情 │ │ │ - Endpoint响应时间 │ │ │ │ - Endpoint吞吐量 │ │ │ │ - Endpoint错误率 │ │ │ │ - 关联Trace列表 │ │ │ └─────────────────────────┘ │ │ │ │ │ │ 选择某个Trace │ │ ▼ │ │ ┌─── Trace View ─────────┐ 链路视角：单次请求的完整调用链 │ │ │ - Span瀑布图 │ │ │ │ - Span详情 │ │ │ │ - 错误信息 │ │ │ └─────────────────────────┘ │ │ │ │ 导航逻辑：全局 → 服务 → 接口 → 链路 │ │ 问题排查：先看全局 → 定位服务 → 找到接口 → 分析链路 │ └──────────────────────────────────────────────────────────────────┘

1.2 四大核心指标

每个层级都有四大核心指标，它们是作战地图的四个指南针：

Apdex（应用性能指数）

Apdex是衡量用户满意度的标准化指标，取值范围0-1。计算公式基于响应时间阈值（T）：

┌──────────────────────────────────────────────────────────────────┐ │ Apdex 计算规则 │ │ │ │ 响应时间 ≤ T → 满意（Satisfied） → 计1分 │ │ T < 响应时间 ≤ 4T → 可容忍（Tolerating） → 计0.5分 │ │ 响应时间 > 4T → 不满意（Frustrated） → 计0分 │ │ │ │ Apdex = (满意数 + 可容忍数×0.5) / 总请求数 │ │ │ │ 示例：T=500ms │ │ ┌──────────────────────────────────────────────────┐ │ │ │ 响应100ms → 满意 → 1分 │ │ │ │ 响应800ms → 可容忍 → 0.5分 │ │ │ │ 响应2s → 不满意 → 0分 │ │ │ │ 响应50ms → 满意 → 1分 │ │ │ │ ──→ Apdex = (2×1 + 1×0.5 + 1×0) / 4 = 0.625 │ │ │ └──────────────────────────────────────────────────┘ │ │ │ │ 阅读方式： │ │ Apdex > 0.9 → 用户很满意（绿灯） │ │ Apdex 0.7-0.9 → 基本满意（黄灯） │ │ Apdex < 0.7 → 用户体验差（红灯） │ └──────────────────────────────────────────────────────────────────┘

T值可以在OAP的alarm-settings.yml中配置：

# alarm-settings.ymlservice_apdex_rule:# Apdex阈值（毫秒）threshold:500

响应时间

响应时间指标包括P50/P75/P90/P95/P99多个百分位数。为什么看百分位数而不是平均值？因为平均值会被极端值拉偏——就像一个班级里有1个考了0分和99个考了100分，平均分99分，看起来很好，但那个0分的学生被掩盖了。

百分位	含义	关注度
P50	50%请求的响应时间	基本了解
P75	75%请求的响应时间	日常监控
P90	90%请求的响应时间	性能标准
P99	99%请求的响应时间	深度优化

吞吐量（Throughput）

吞吐量表示单位时间内的请求数（CPM = Calls Per Minute）。它是系统负载的直观指标——就像城市的车流量，高峰期堵车，低谷期畅通。

错误率（Error Rate）

错误率表示失败请求占总请求的百分比。任何大于0的错误率都应该引起注意——就像作战中的伤亡率，哪怕只有0.1%的伤亡，也意味着有人在遭受损失。

2. 拓扑图的读法

2.1 拓扑图是什么

拓扑图是SkyWalking UI中最直观的视图——它把微服务之间的调用关系画成了一张地图。就像城市的交通地图——每条道路是调用链路，每个节点是服务，道路上的数字是流量和延迟。

2.2 拓扑图的元素解读

┌──────────────────────────────────────────────────────────────────┐ │ 拓扑图元素解读 │ │ │ │ ┌─── Service Node ──────────────────────────────────┐ │ │ │ ┌───────────────┐ │ │ │ │ │ user-service │ ← 服务名 │ │ │ │ │ │ │ │ │ │ │ Apdex: 0.92 │ ← 满意度 │ │ │ │ │ CPM: 150 │ ← 每分钟调用数 │ │ │ │ │ │ │ │ │ │ │ ■ 绿色 │ ← Apdex>0.9 绿色（健康） │ │ │ │ │ ■ 黄色 │ ← Apdex 0.7-0.9 黄色（警告） │ │ │ │ │ ■ 红色 │ ← Apdex<0.7 红色（危险） │ │ │ │ └───────────────┘ │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ ┌─── Link (调用链路) ────────────────────────────────┐ │ │ │ │ │ │ │ user-service ────→ order-service │ │ │ │ │ │ │ │ │ │ 调用信息标签： │ │ │ │ │ CPM: 120 │ ← 链路每分钟调用量 │ │ │ │ P99: 350ms │ ← 链路P99延迟 │ │ │ │ Error: 2% │ ← 链路错误率 │ │ │ │ │ │ │ │ 链路颜色： │ │ │ │ 绿色 → 正常 黄色 → P99较高 红色 → 错误率高 │ │ │ └────────────────────────────────────────────────────┘ │ │ │ │ ┌─── 特殊节点 ──────────────────────────────────────┐ │ │ │ │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │ User │ │ Database│ │ MQ │ │ │ │ │ │(起点) │ │(存储) │ │(中间件) │ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ User = 外部调用者 Database = 数据库节点 │ │ │ │ MQ = 消息队列 Cache = 缓存节点 │ │ │ └────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘

2.3 拓扑图的阅读技巧

技巧一：找红色节点

红色节点是Apdex<0.7的服务——它们是作战地图上的"受伤部队"。优先关注这些节点。

技巧二：找红色链路

红色链路是错误率>0的调用——它们是"受伤的运输线路"。沿着红色链路追踪，通常能找到问题根源。

技巧三：看链路的CPM和P99

高CPM + 高P99的链路是系统的热点瓶颈——就像交通地图上车流量大又堵车的路段。优化这些链路能最大化改善系统性能。

技巧四：追踪链路方向

从User节点出发，沿着调用链路的方向追踪——这就是一个请求的完整旅程。哪个链路延迟高，哪个节点出错，一目了然。

3. Trace视图的组成

3.1 Span瀑布图

Trace视图是SkyWalking UI中最强大的功能——它把一次请求的所有调用按时间排列成瀑布图。就像作战日志中的时间线——每一秒发生了什么，谁调用了谁，花了多长时间：

┌──────────────────────────────────────────────────────────────────┐ │ Trace Span 瀑布图结构 │ │ │ │ TraceID: a3b2c1d4e5f6 │ │ Span数: 8 │ │ 总耗时: 650ms │ │ │ │ ┌─ Span0: user-service /api/users/{id} ────────────── 0-650ms │ │ │ ┌─ Span1: order-service /getUserOrder ────── 50-350ms │ │ │ │ ┌─ Span2: mysql SELECT * FROM orders ──── 60-180ms │ │ │ │ └─ Span3: redis GET user:123 ────────── 200-250ms │ │ │ └─ Span4: payment-service /checkPayment ── 380-550ms │ │ │ └─ Span5: mysql SELECT * FROM payments ── 400-500ms │ │ │ ┌─ Span6: notify-service /sendSMS ──────── 400-600ms │ │ │ │ └─ Span7: kafka PRODUCE notify-topic ─── 420-580ms │ │ │ │ │ │ 阅读方式： │ │ │ 左边 = Span名（服务+操作） │ │ │ 横轴 = 时间线 │ │ │ 条长 = 耗时长 │ │ │ 嵌套 = 调用关系 │ │ │ 红色 = 错误Span │ │ └─────────────────────────────────────────────────────────────│ │ │ │ 定位问题的方法： │ │ 1. 找最长的Span → 拖慢请求的瓶颈 │ │ 2. 找红色的Span → 出错的环节 │ │ 3. 看嵌套关系 → 谁调用了谁 │ │ 4. 看时间间隙 → 有没有不必要的等待 │ └──────────────────────────────────────────────────────────────────┘

3.2 Span的类型和标签

每个Span都携带丰富的标签信息，点击Span可以查看详情：

标签类型	示例	说明
component	mysql / redis / kafka	使用的组件
db.type	mysql / postgresql	数据库类型
db.instance	user_db	数据库实例
db.statement	SELECT * FROM users WHERE id=?	SQL语句
http.method	GET / POST	HTTP方法
http.url	/api/users/123	URL路径
http.status_code	200 / 500	HTTP状态码
mq.topic	order-created	消息主题
mq.broker	kafka-broker:9092	消息中间件地址

3.3 Trace列表页的使用

Trace列表页可以按条件筛选Trace：

# 常用筛选条件：# - TraceID：精确搜索某个Trace# - 服务名：某个服务的所有Trace# - Endpoint名：某个API的所有Trace# - 时间范围：指定时间段# - 状态：成功/错误# - 响应时间：慢请求（>某阈值）# - Tag：按标签搜索（如db.statement包含某SQL）

4. 告警面板

4.1 告警面板的组成

告警面板展示所有触发的告警事件，按时间和严重程度排列：

┌──────────────────────────────────────────────────────────────────┐ │ 告警面板的元素 │ │ │ │ ┌─── 告警列表 ────────────────────────────────────────┐ │ │ │ │ │ │ │ 🔴 14:30 user-service 响应时间P99 > 3000ms │ │ │ │ 规则: service_p99_rule │ │ │ │ 详情: P99=3500ms, 阈值=3000ms │ │ │ │ │ │ │ │ 🔴 14:25 order-service 错误率 > 5% │ │ │ │ 规则: service_error_rate_rule │ │ │ │ 详情: 错误率=8.2%, 阈值=5% │ │ │ │ │ │ │ │ 🟡 14:20 payment-service Apdex < 0.7 │ │ │ │ 规则: service_apdex_rule │ │ │ │ 详情: Apdex=0.65, 阈值=0.7 │ │ │ │ │ │ │ │ 每条告警包含： │ │ │ │ - 时间：何时触发 │ │ │ │ - 对象：哪个服务/Endpoint │ │ │ │ - 规则：哪个告警规则 │ │ │ │ - 详情：当前值和阈值 │ │ │ └──────────────────────────────────────────────────────┘ │ │ │ │ 点击告警 → 跳转到对应的Trace列表 → 找到问题Trace │ └──────────────────────────────────────────────────────────────────┘

4.2 告警规则配置

告警规则在OAP Server的alarm-settings.yml中配置：

# alarm-settings.ymlrules:# 服务响应时间告警service_resp_time_rule:metrics-name:service_resp_timeop:">"threshold:3000period:10count:3silence-period:5message:服务{name}响应时间超过3秒，最近10分钟内出现3次# 服务错误率告警service_error_rate_rule:metrics-name:service_error_rateop:">"threshold:5period:10count:3message:服务{name}错误率超过5%# Endpoint响应时间告警endpoint_resp_time_rule:metrics-name:endpoint_resp_timeop:">"threshold:1000period:10count:3message:接口{name}响应时间超过1秒

告警规则的关键参数：

参数	含义
metrics-name	监控的指标名
op	比较运算符（>/>=/<等）
threshold	阈值
period	统计周期（分钟）
count	在period内触发多少次才告警
silence-period	告警静默期（避免重复告警）
message	告警消息模板

5. UI自定义Dashboard技巧

5.1 自定义Dashboard的作用

SkyWalking UI支持创建自定义Dashboard——就像在作战地图上画出你关心的区域。你可以把不同服务的关键指标放在一个面板中，快速对比。

5.2 创建自定义Dashboard

步骤：

在UI左侧菜单点击"Dashboard"
点击右上角的"New Dashboard"按钮
选择Dashboard类型（Global/Service/Endpoint/Instance）
添加你关心的指标组件
调整布局和大小

自定义Dashboard支持的组件类型：

┌──────────────────────────────────────────────────────────────────┐ │ Dashboard组件类型 │ │ │ │ ┌─── Line Chart ───┐ 时间趋势线 │ │ │ 响应时间趋势 │ 适合：看指标随时间的变化 │ │ └───────────────────┘ │ │ │ │ ┌─── Bar Chart ────┐ 柱状图对比 │ │ │ 各服务CPM对比 │ 适合：多个对象的横向对比 │ │ └───────────────────┘ │ │ │ │ ┌─── TopN Chart ───┐ 排行榜 │ │ │ 慢请求Top10 │ 适合：找出最慢/最热的N个对象 │ │ └───────────────────┘ │ │ │ │ ┌─── Percent ──────┐ 百分比 │ │ │ Apdex百分比 │ 适合：显示占比类指标 │ │ └───────────────────┘ │ │ │ │ ┌─── Area Chart ───┐ 面积图 │ │ │ 吞吐量分布 │ 适合：看总量和组成 │ │ └───────────────────┘ │ └──────────────────────────────────────────────────────────────────┘

5.3 实用Dashboard模板

核心业务健康面板

创建一个Global类型的Dashboard，集中展示核心业务服务的健康状态：

# 推荐组件配置：# 1. Apdex TopN - 找出Apdex最低的服务（最不满意）# 2. 响应时间P99 TopN - 找出最慢的服务# 3. 错误率 TopN - 找出出错最多的服务# 4. 吞吐量TopN - 找出流量最大的服务# 5. 全局Apdex趋势 - 看整体满意度变化

慢请求分析面板

创建一个Service类型的Dashboard，专门分析慢请求：

# 推荐组件配置：# 1. Endpoint响应时间P99排行 - 最慢的API# 2. Endpoint响应时间趋势 - 慢API是否越来越慢# 3. Trace列表筛选慢请求 - 慢请求的链路详情# 4. 数据库操作TopN - 最慢的SQL

数据库性能面板

创建一个Service类型的Dashboard，专门看数据库性能：

# 推荐组件配置：# 1. 数据库操作响应时间TopN - 最慢的SQL# 2. 数据库操作吞吐量 - SQL执行频率# 3. 数据库错误率 - 失败的SQL操作

6. UI快捷操作

6.1 时间范围选择

UI右上角有一个时间选择器——选择查看哪个时间段的数据。快捷选项：

选项	时间范围	适用场景
最近15分钟	-15m	实时监控
最近30分钟	-30m	短期异常
最近1小时	-1h	问题排查
最近6小时	-6h	趋势分析
最近1天	-1d	日常回顾
最近7天	-7d	周报分析

6.2 自动刷新

可以设置Dashboard的自动刷新间隔：

选项	间隔	适用场景
不刷新	-	静态分析
5秒	5s	实时监控
15秒	15s	日常巡检
30秒	30s	一般监控

6.3 Trace搜索技巧

# 搜索特定服务的慢Trace# 条件：服务名=user-service, 响应时间>500ms# 搜索特定API的错误Trace# 条件：Endpoint=/api/orders, 状态=错误# 搜索包含特定SQL的Trace# 条件：Tag=db.statement 包含 "SELECT * FROM orders"# 搜索特定TraceID# 条件：TraceID=abc123def456