SkyWalking UI、拓扑与 Trace 分析
SkyWalking UI 用于从全局概览逐步下钻到服务、实例、端点和单条 Trace。排障时应先用指标确定影响范围，再用拓扑和 Trace 定位调用链，最后回到应用日志和发布记录确认根因。
1. Dashboard 四个维度
| 维度 | 适合回答的问题 | 常用信号 |
|---|---|---|
| Global | 哪些服务、端点或时间段出现整体异常？ | CPM、慢服务、Apdex、P95/P99、热力图 |
| Service | 哪个服务的成功率、平均延迟或吞吐量异常？ | Service Apdex、成功率、响应时间分位数 |
| Instance | 异常是否集中在单个 Pod、主机或 JVM？ | 实例延迟、JVM CPU、内存、GC 时间与次数 |
| Endpoint | 哪个接口路径或 RPC 方法变慢、报错或流量异常？ | Endpoint Load、平均延迟、响应时间分位数 |
Global 指标
| 指标 | 含义 | 排查提示 |
|---|---|---|
| CPM | 每分钟调用数 | 与发布、流量活动和限流事件对照 |
| Slow Services | 慢响应服务 | 下钻到 Service 与依赖调用确认瓶颈 |
| Un-Health Services (Apdex) | 用户体验评分异常的服务 | 先确认阈值配置和真实业务 SLO |
| Slow Endpoints | 全局最慢端点 | 检查接口、数据库、缓存和下游依赖 |
| Response Latency Percentile | 响应延迟分位数 | 重点看 P95/P99，而非只看平均值 |
| Heatmap | 延迟在时间段内的分布 | 识别偶发慢请求还是整体性能退化 |
Service 与 Instance 指标
服务维度关注 Apdex、成功率、平均响应时间、分位数和吞吐量；指标的含义如下。
| 指标 | 含义 | 排查提示 |
|---|---|---|
| Service Apdex | 当前服务的用户体验评分 | 先确认评分阈值与业务 SLO 是否匹配 |
| Service Avg Response Times | 平均响应时间 | 易受少量慢请求影响，应同时看分位数 |
| Service Response Time Percentile | 响应时间分位数 | 用 P95/P99 判断长尾延迟 |
| Successful Rate | 请求成功率 | 和错误码、异常 Trace、发布事件交叉核对 |
| Service Load | 每分钟请求数 | 对照流量变化、限流和扩缩容事件 |
| Service Throughput (Bytes) | TCP 服务的吞吐量 | 仅适用于 TCP 服务，和网络及下游负载一起判断 |
实例维度用于确认异常是否集中在某一个 Pod 或主机。Java 服务还应结合以下 JVM 指标判断是否存在资源或垃圾回收问题。
| 指标 | 含义 | 排查提示 |
|---|---|---|
| Service Instance Successful Rate | 当前实例的请求成功率 | 与同服务其他实例比较，识别局部故障 |
| Service Instance Latency | 当前实例的响应时间 | 与节点资源、连接数和 GC 时间关联分析 |
| JVM CPU | JVM 占用 CPU 的百分比 | 持续高占用需结合线程、热点方法和限额检查 |
| JVM Memory | JVM 堆内与堆外内存使用量 | 区分正常缓存增长与内存泄漏 |
| JVM GC Time | 垃圾回收耗时 | 停顿升高常会放大接口延迟 |
| JVM GC Count | 垃圾回收次数 | 频繁 Full GC 需要检查堆大小和对象分配 |
Endpoint 指标
Endpoint 是最适合定位接口级性能问题的维度。比较端点的 QPS、平均响应时间和分位数时，要按环境、服务版本和流量来源筛选，避免把灰度流量、压测流量和生产请求混在一起。
| 指标 | 含义 | 排查提示 |
|---|---|---|
| Endpoint Load in Current Service | 当前服务中端点每分钟请求数 | 明确端点流量是否异常或倾斜 |
| Slow Endpoints in Current Service | 当前服务中最慢的端点 | 从对应的慢 Trace 下钻数据库和远程调用 |
| Endpoint Load | 端点在各时间段的请求量 | 与发布、营销和定时任务事件对照 |
| Endpoint Avg Response Time | 端点在各时间段的平均响应时间 | 结合分位数排除少量极端值干扰 |
| Endpoint Response Time Percentile | 端点响应时间分位数 | 用 P95/P99 观察长尾问题是否持续 |
2. 服务拓扑
拓扑图展示用户、应用、数据库和依赖之间的请求路线。它用于发现依赖关系、确认调用方向，并快速判断某个异常是否来自共同下游。
拓扑并非自动等于完整系统架构：未接入 Agent 的服务、异步消息、采样不足或未支持的协议都可能形成空洞。将它作为运行时依赖证据，并与服务目录、Kubernetes 资源和变更记录交叉验证。
3. Trace 下钻
Trace 视图可列出一次请求的服务调用、方法、耗时和异常信息，适合开发与运维共同定位具体请求的慢点和错误传播路径。
推荐的排障顺序：
- 在 Global 或 Service 找到异常时间窗口与受影响服务。
- 在 Endpoint 筛选慢请求或错误请求，记录 Trace ID。
- 打开 Trace，比较各 Span 的耗时、状态码、数据库和远程调用。
- 将 Trace ID 关联到应用日志，并核对该时间点的发布、配置和基础设施事件。
- 修复后重新观察分位数、成功率与新的 Trace，确认不是只恢复了单个请求。
4. 使用边界
- 不要将请求体、Authorization、Cookie、身份证号或其他敏感参数直接采集到 Tag、Log 或 Trace。
- 高流量服务应基于错误率、延迟阈值或关键交易配置采样，避免全量采样导致 OAP 和存储压力失控。
- Dashboard 中的单个指标只能描述现象；根因需要结合 Trace、日志、指标与变更记录交叉确认。
- 对 UI、GraphQL 接口和 Trace 查询设置访问控制，追踪数据可能包含业务路径和内部服务信息。