Skywalking使用说明

需求背景

随着分布式的盛行，系统的复杂度也逐步增加，不同服务间的交互对性能的定位提出了更高的要求。任意一个节点的异常，都可能对业务系统造成损失。对于链路追踪，迫切需要一个优秀的监测工具。

需求如下

功能性需求

• 请求链路追踪，快速定位故障，缩短故障的排除时间 以及 判断故障影响范围
• 可视化链路各阶段的耗时，进行性能分析，排除业务瓶颈
• 梳理服务依赖关系以及优化依赖的合理性
• 系统指标监控，吞吐量（TPS）、响应时间及错误记录等。

非功能性需求：

探针的性能消耗：服务调用埋点本身会带来性能损耗，这就需要组件对业务系统的性能影响小
代码的侵入性：对业务系统尽可能少入侵或者无入侵其他，对于使用方透明，减少开发人员的负担。

Skywalking

• 简介

一款全链路追踪的工具

使用说明如下

仪表盘

仪表盘是Skywalking的首页，它提供多个指示板来可视化指标，例如：服务(APM)、数据库（Database）等等。

APM

APM面板总体分为四个维度：Global（全局）、Service（服务）、Instance（实例）、Endpoint（API），提供筛选功能，每块都包含一些指标。

• Global（全局）指标：

1、Services Load：

服务每分钟请求数

2、Slow Services：
慢响应服务，按响应时间排序topN，单位ms

3、Un-Health Services (Apdex)：

Apdex性能指标，即服务的不健康值，1为满分，Apdex是根据设定的阈值和响应时间综合考虑的衡量标准，是满意响应时间和不满意响应时间相对于总响应时间的比率，衡量的是用户对服务的满意程度，因为传统的指标（如平均响应时间）可能很快就会容易形成偏差。

4、Slow Endpoints：

慢接口平均响应耗时排序，单位ms

5、Global Response Latency：

响应时间百分比，不同百分比的延时时间，单位ms。percentile 标签含义，例如 p99 为 3500ms，意味着 99% 的请求应该比 3500ms 更快

6、Global Heatmap：

服务响应时间热力分布图，根据时间段内不同响应时间的数量显示颜色深度, 颜色越深，请求越多。

• Service（服务）维度：**

Service Apdex 数字：
Apdex性能指标

Service Apdex 折线图：
一段时间的Apdex分数

Service Avg Response Time：
服务平均响应时间

Service Response Time Percentile：
百分比响应延时

**Successful Rate（%）**数字：
请求成功率

**Successful Rate（%）折线图：**一段时间的请求成功率
**Service Load（CPM - calls per minute）：
**每分钟调用数

Service Load（CPM - calls per minute）：

一段时间的每分钟调用数

Service Instances Load（CPM - calls per minute）：

每个实例每分钟请求数

Slow Service Instance：

每个服务实例平均延时topN

Service Instance Successful Rate：

服务实例的请求成功率 topN

• Instance（实例）维度：

• Endpoint（API）维度：

Database（数据库）：

拓扑图

拓扑图可以很直观地展示服务与服务之间的依赖关系，这对于我们进行服务梳理是非常有帮助的，并且支持自定义分组，如下图所示，就将 ai-search、social-search、social-scan 三个服务自定义一个分组，并通过拓扑图很直观地展示出三者间的依赖关系：

除此之外，拓扑图还能查看服务运行信息进行度量，包括开发框架类型、服务平均响应时间、吞吐量、百分比响应、Apdex分值、SLA值等

链路追踪：

• 查看数据库操作详情：

• 查看Redis缓存操作详情：

性能剖析：

Skywalking 在性能剖析方面非常强大，提供到基于堆栈的分析结果，能够让开发人员一看看出调用过程中各个步骤所消耗的时间，以便进行有针对性的进行优化。

性能剖析通过新建任务，对不同端点进行采样，提供更详细的报告，比如比链路追踪多了线程栈的信息、慢方法提示等等内容。接下来我们就介绍下怎么进行性能剖析：

• 新建任务：
  在 性能剖析模块 -> 新建任务 -> 选择服务、填写端点、监控时间，操作如下图：

温馨提示：每个服务，相同时间只能添加一个任务，且添加的任务不能更改也不能删除，只能等待过期后自动删除

• 执行请求：
  多次访问 “/api/searchByWholeOcr” 接口，然后选择这个任务将会出现监控到的数据，如下图：

备注：需要连续执行多次请求，因为存在采用设置。如果执行次数少，可能不会出现采样数据，也就无法进行分析了

性能剖析：

上图可以看出，”/api/searchByWholeOcr“ 接口耗费了681ms，通过分析详细堆栈信息，我们可以看到耗时最多的操作就是SearchServiceImpl 类的 executeSearchRequest()方法，耗费了563ms，主要是调用 ES 做了全文搜索，如下图所示：

写在最后

Skywaling是一个很好的链路追踪的工具，尤其是在生产环境，对于定位接口耗时，链路过程有着重要的辅助作用。对于它的使用，至少得看得懂，才知道怎么定位问题。这里是"安前码后"，一个专注分享实用干货的号，觉得用心整理并且对看官们有帮助的，请给个三连。更多实用干货持续更新中…

本文由mdnice多平台发布