SkyWalking Web UI 实战指南：从入门到精通

1. SkyWalking Web UI 初识：监控系统的"控制面板"

第一次打开SkyWalking Web UI时，就像走进了一个现代化的飞机驾驶舱——各种仪表盘和数据视图让人眼花缭乱。但别担心，这个"驾驶舱"设计得非常人性化。作为分布式系统的"健康监测仪"，它能实时展示你的应用集群运行状态，从宏观拓扑到微观调用链路一览无余。

我刚开始使用时最常访问的是Dashboard（仪表盘），这里就像监控系统的"指挥中心"。最上方的时间选择器特别实用，可以查看任意时间段的监控数据。记得有次线上问题排查，就是通过调整时间范围定位到了凌晨3点的异常流量高峰。热力图（Calls HeatMap）用颜色深浅直观显示请求量和响应时间，红色区域往往就是需要重点关注的性能瓶颈。

左侧导航栏的六个核心模块构成了完整的监控体系：

• Topology：系统架构的"鸟瞰图"
• Application：应用级别的深度体检
• Service：API粒度的性能分析
• Alarm：系统健康的预警哨兵
• Trace：请求链路的显微镜

2. 拓扑视图：绘制你的系统地图

2.1 拓扑图的三种观察视角

第一次看到拓扑图时，我被那些闪烁的连线和彩色节点吸引了。这就像给你的系统架构拍X光片，User→Application→Middleware的调用关系一目了然。实测发现三种视图切换特别实用：

1. 用户视角（默认）：显示终端用户到应用的访问路径
2. 应用视角：聚焦应用间的调用依赖
3. 服务视角：展示API级别的调用链

有次排查线上问题，就是通过切换应用视角，发现某个微服务异常导致调用链断裂。图中红色告警节点会实时闪烁，点击节点可以看到具体的错误率和响应时间。

2.2 拓扑图实战技巧

在Filter Application输入框里，可以输入应用名进行筛选。这个功能在我们有50+微服务的系统中特别有用。几个实用技巧：

• 按住Ctrl+鼠标滚轮可以缩放视图
• 拖动节点可以重新布局
• 右键点击节点可以快速跳转到对应应用的详情页

# 小贴士：如果拓扑图显示不全 # 检查SkyWalking agent的service_name配置是否唯一 agent.service_name=${SW_AGENT_NAME:Your_ApplicationName}

3. 应用监控：给每个服务做全面体检

3.1 应用总览的黄金指标

进入Application页面就像打开服务的体检报告，几个关键指标需要特别关注：

• Throughput（吞吐量）：CPM值反映服务处理能力
• Response Time（响应时间）：超过500ms就需要警惕
• SLA（服务可用性）：99.9%是常见基准线

我习惯先看Slow Service榜单，这里会列出响应最慢的Top10服务。有次发现一个查询接口平均响应2秒，优化SQL后整体性能提升了40%。

3.2 JVM监控：深入Java应用内核

点击More Server Details会打开宝藏功能——JVM监控面板。这里可以看到：

• 内存使用曲线（堆内存/非堆内存）
• GC次数和时间统计
• 线程状态分布图
• CPU负载情况

曾经通过这个面板发现内存泄漏：堆内存使用曲线呈"锯齿状"但基线持续上升，最终定位到是缓存没有设置过期时间。

4. 链路追踪：还原请求的完整旅程

4.1 Trace查询的六种武器

Trace功能是我使用最频繁的模块，就像侦探的放大镜。高级查询支持多种过滤方式：

1. 时间范围选择（精确到分钟）
2. 应用/服务筛选
3. 状态过滤（成功/失败）
4. 耗时区间设置
5. TraceID精确查询
6. 标签条件过滤

// 开发时建议添加的Trace标签 ActiveSpan.tag("http.method", "GET"); ActiveSpan.tag("db.type", "mysql");

4.2 Span分析的三个要点

点击具体的Trace会展示完整的调用树，每个Span都包含丰富信息：

• 基础信息：开始时间、耗时、组件类型
• 标签数据：包含SQL语句、HTTP状态码等
• 日志信息：异常堆栈等详细信息

排查问题时我通常会：

1. 先看整体链路长度和深度
2. 筛选出error状态的Span
3. 检查耗时最长的Span详情

5. 告警中心：系统的预警雷达

5.1 告警配置实战

Alarm页面默认显示最近6小时的告警信息。在实际项目中，我建议通过alarm-settings.yml配置自定义规则：

rules: service_resp_time_rule: metrics-name: service_resp_time op: ">" threshold: 1000 period: 10 count: 3 silence-period: 5 message: 服务{name}响应时间超过1秒

5.2 告警分级策略

根据经验，告警应该分级处理：

• P0级（页面自动刷新告警）：影响核心业务流程
• P1级（邮件通知）：重要指标异常
• P2级（每日汇总）：需要优化但不紧急

6. 性能优化实战案例

6.1 慢查询优化过程

曾经处理过一个典型案例：通过Trace发现某个订单查询接口平均耗时2.3秒。分析过程：

1. 在Trace中定位到最耗时的Span
2. 查看标签发现执行了5次SQL查询
3. 检查SQL语句发现N+1查询问题
4. 优化为JOIN查询后降至400ms

6.2 线程池调优

通过JVM监控发现某服务线程数持续增长：

1. 观察Thread Count图表确认趋势
2. 结合GC日志分析内存变化
3. 定位到线程池未正确关闭
4. 改用Spring管理的线程池解决问题

7. 日常运维最佳实践

7.1 监控看板配置技巧

对于重要服务，建议创建自定义Dashboard：

1. 固定关键业务指标
2. 设置合适的刷新频率（生产环境建议30秒）
3. 添加对比时间段（如同比上周）
4. 保存常用查询条件

7.2 数据清理策略

SkyWalking数据默认存储15天，可以通过以下方式调整：

# 修改config/application.yml storage: elasticsearch: dayStep: 1 indexShardsNumber: 2 indexReplicasNumber: 0 ttl: 30

在实际使用过程中，我发现将TTL设置为7天既能满足日常排查需求，又能节省50%存储空间。对于特别重要的服务，可以通过Export Trace功能备份特定链路数据。