链路追踪SkyWalking

一、什么是SkyWalking？

** skywalking是一个优秀的国产开源框架，2015年由个人吴晟（华为开发者）开源。目前已被被Apache收入麾下。skywalking支持dubbo，SpringCloud，SpringBoot集成，代码无侵入，通信方式采用GRPC，性能较好，实现方式是java探针，支持告警，支持JVM监控，支持全局调用统计等等，功能较完善。**

二、选择SkyWalking的优势

• 采用字节码增强的技术实现代码无侵入。
• 功能比较丰富，报表统计，UI界面更加人性化。

三、Skywalking架构

• 上面的Agent：负责收集日志数据，并且传递给中间的OAP服务器
• 中间的OAP：负责接收 Agent 发送的 Tracing 和Metric的数据信息，然后进行分析(Analysis Core) ，存储到外部存储器( Storage )，最终提供查询( Query )功能。
• 左面的UI：负责提供web控制台，查看链路，查看各种指标，性能等等。
• 右面Storage：负责数据的存储，支持多种存储类型。
  整张图的意思就是：Agent负责收集日志传输数据，通过GRPC的方式传递给OAP进行分析并且存储到数据库中，最终通过UI界面将分析的统计报表、服务依赖、拓扑关系图展示出来。

四、服务端搭建

skywalking是通过jar包方式启动，需要下载jar包，地址：https://skywalking.apache.org/downloads/

1. 下载安装包

我选择了V9.2.0版本，如下图：

解压后如下：

skywalking8.7.0之后的版本，agent的相关代码被抽离出skywalking当中，需要自行下载agent。
如上图是将下载好的解压到skywalking目录中。
重要的目录结构分析如下：

• agent：客户端需要指定的目录，其中有一个jar，就是负责和客户端整合收集日志
• bin：服务端启动的脚本
• config：一些配置文件的目录
• logs：oap服务的日志目录
• oap-libs：oap所需的依赖目录
• webapp：UI服务的目录

2. 配置修改

启动之前需要对两个配置文件做一些修改，修改如下：
第一个配置文件：/config/application.yml
这个是oap服务的配置文件，需要修改注册中心为nacos，如下图：

红框1：修改默认注册中心选择nacos，这样就不用在启动参数中指定了。
红框2：修改nacos的相关配置，由于我是本地启动的nacos，则不用改动，根据自己情况修改。

第二个配置文件： webapp/webapp.yml
这个是UI服务的配置文件，其中有一个server.port配置，是UI服务的端口，默认8080，将它改为其它端口，例如我改为8899，避免端口冲突，如下图：

3. 启动服务

启动命令在/bin目录下，这里需要启动两个服务，如下：

• oap服务：对应的启动脚本oapService.bat，Linux下对应的后缀是sh
• UI服务：对应的启动脚本webappService.bat，Linux下对应的后缀是sh

PS：skywalking包含两个服务oapService，webappService，oapService为skywalking的后端服务。需要占用11800、12800端口。
11800端口用于跟agent进行交互，获取agent探针到的数据。
12800端口用户跟UI界面的交互，将agent探针到的数据展示在UI界面。

当然还有一个startup.bat启动文件，可以直接启动上述两个服务，我们可以直接使用这个脚本，直接双击，将会弹出两个窗口则表示启动成功，如下图：

此时直接访问：http://localhost:8899/，直接进入UI端，如下图：

五、客户端搭建

客户端也就是单个服务，由于Skywalking采用字节码增强技术，因此对于服务无代码侵入，只要是普通的服务即可，不需要引入什么依赖。
使用智慧云平台两个服务做例子：

• skywalking-01：wisdom-content-issued
• skywalking-02：wisdom-back-stage
  想要传输数据必须借助skywalking提供的agent，只需要在启动参数指定即可，命令如下：
  -javaagent:D:\SkyWalking\apache-skywalking-apm-9.2.0\apache-skywalking-apm-bin\agent\skywalking-agent\skywalking-agent.jar
  -Dskywalking.agent.service_name=test-xxxx
  -Dskywalking.collector.backend_service=127.0.0.1:11800
• -javaagent：指定skywalking中的agent中的skywalking-agent.jar的路径
• -Dskywalking.agent.service_name：指定在skywalking中的服务名称，一般是微服务的spring.application.name
• -Dskywalking.collector.backend_service：指定oap服务绑定的地址，由于我这里是本地，并且oap服务默认的端口是11800，因此只需要配置为127.0.0.1:11800
  上述参数可以在命令行通过java -jar xxx指定，在IDEA中操作如下图：

上述两个服务都需要配置skywalking的启动配置，配置成功后正常启动即可。

PS:注意：agent的jar包路径不能包含中文，不能有空格，否则运行不成功。

成功启动后，直接通过访问：http://localhost:8088/wisdom_platform/wisdomStage/wisdomCard/card/networkApi/verify

此时查看skywalking的UI端，可以看到三个服务已经监控成功了，如下图：

图就不发了

服务之前的依赖关系也是可以很清楚的看到，如下图：

图就不发了

请求链路的信息也是能够很清楚的看到，比如请求的url，执行时间、调用的服务，如下图：

图就不发了

六、数据持久化

你会发现只要服务端重启之后，这些链路追踪数据将会丢失了，因为skywalking默认持久化的方式是存储在内存中。当然这里也是可以通过插拔方式的替换掉存储中间件，我在这里使用MySQL的方式存储测试，一般都使用ES存储。
注意：MYSQL建库采用latin1字符编码，可以避免索引长度的问题，表的创建是自动的。

1. 修改配置文件

修改config/application.yml文件中的存储方式，总共需要修改两处地方。

• 修改默认的存储方式为mysql，如下图：

• 修改Mysql相关的信息，比如用户名、密码等，如下图：

2. 添加MySQL的jdbc依赖

默认的oap中是没有jdbc驱动依赖，因此需要我们手动添加一下，只需要将驱动的jar放在
oap-libs文件夹中，如下图：

好了，已经配置完成，启动服务端，在skywalking这个数据库中将会自动创建表，如下图：

七、日志监控

在skywalking的UI端有一个日志的模块，用于收集客户端的日志，默认是没有数据的，那么需要如何将日志数据传输到skywalking中呢？
日志框架的话我选用logback，其它的log4j、log4j2也行。

1. 添加依赖

<dependency>
    <groupId>org.apache.skywalkinggroupId>
    <artifactId>apm-toolkit-logback-1.xartifactId>
    <version>8.12.0version>
dependency>

2. 添加配置文件

<appender name="grpc-log" class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.log.GRPCLogClientAppender">
    <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
        <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.mdc.TraceIdMDCPatternLogbackLayout">
            <Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%X{tid}] [%thread] %-5level %logger{36} -%msg%nPattern>
        layout>
    encoder>
appender>

配置完成之后，启动服务，访问：http://localhost:8088/wisdom_platform/wisdomStage/wisdomCard/card/networkApi/verify，如果有在logback-spring.xml配置日志输出，即可在控制台看到打印traceId，我这里没有配置。
在skywalking中的日志模块输出的日志如下图：

日志已经传输到了skywalking中了。
在上面也说了，skywalking有两个服务，如果agent跟oap服务不在同一台服务器上，需要在
agent\skywalking-agent\config\agent.config配置文件末尾添加如下配置：

// 指定要向其报告日志数据的grpc服务器的主机
plugin.toolkit.log.grpc.reporter.server_host=${SW_GRPC_LOG_SERVER_HOST:x.x.x.x}
// 指定要向其报告日志数据的grpc服务器的端口
plugin.toolkit.log.grpc.reporter.server_port=${SW_GRPC_LOG_SERVER_PORT:11800}
// 指定grpc客户端要报告的日志数据的最大大小
plugin.toolkit.log.grpc.reporter.max_message_size=${SW_GRPC_LOG_MAX_MESSAGE_SIZE:10485760}
// 客户端向上游发送数据时将超时多长时间，单位是秒
plugin.toolkit.log.grpc.reporter.upstream_timeout=${SW_GRPC_LOG_GRPC_UPSTREAM_TIMEOUT:30}

八、性能剖析

skywalking在性能剖析方面真的是非常强大，提供到基于堆栈的分析结果，能够让运维人员一眼定位到问题。
创建一个任务，如图：

站点名称即为接口名，接口被请求时此选择这个接口点击分析，可以看到详细的堆栈信息。

九、告警

对于服务的异常信息，比如接口（将接口sleep了2S）有较长延迟，skywalking也做出了告警功能，如下图：

skywalking中有一些默认的告警规则，如下：

• 最近3分钟内服务的平均响应时间超过1秒
• 最近2分钟服务成功率低于80%
• 最近3分钟90%服务响应时间超过1秒
• 最近2分钟内服务实例的平均响应时间超过1秒
  除了以上四种，随着Skywalking不断迭代也会新增其他规则，这些规则的配置在config/alarm-settings.yml配置文件中，有兴趣可以配置下。
  每个规则都由相同的属性组成，这些属性的含义如下图：

当然除了以上默认的几种规则，skywalking还适配了一些钩子（webhooks）。其实就是相当于一个回调，一旦触发了上述规则告警，skywalking则会调用配置的webhook，这样开发者就可以定制一些处理方法，比如发送邮件等通知运维、研发人员处理。
这个钩子也是有些规则的，如下：

• POST请求
• application/json 接收数据
• 接收的参数必须是AlarmMessage中指定的参数。
  注意：AlarmMessage这个类随着skywalking版本的迭代可能出现不同，一定要到对应版本源码中去找到这个类，拷贝其中的属性。这个类在源码的路径org.apache.skywalking.oap.server.core.alarm，如下图：

自己新建接口，如：

@Slf4j
@RequestMapping("/alarm")
@AlarmController {

    @ApiOperation("接受skywalking告警")
    @PostMapping("/receive")
    public void receive(@RequestBody List<AlarmMessage> list) {
        log.info("/alarm/receive:" + JSON.toJSONString(list));
        log.info("微信receive");
    }

}

接口定制完成后，只需要在config/alarm-settings.yml配置文件中添加这个钩子，如下图：

END