链路追踪的另外一种解决方案Skywalking

skywalking支持dubbo，SpringCloud，SpringBoot集成，
代码无侵入，通信方式采用GRPC，性能较好，实现方式是java探针，支持告警，支持JVM监控，支持全局调用统计等等，功能较完善

如何选型？

Skywalking和Spring Cloud Sleuth+ZipKin 如何选型
Skywalking相比于zipkin还是有很大的优势的，如下：

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

个人建议：如果是新的架构，建议优先选择skywalking。

架构

skywalking和zipkin一样，也分为服务端和客户端，
服务端负责收集日志数据并且展示，架构如下：
image.png

  • 上面的Agent：负责收集日志数据，并且传递给中间的OAP服务器
  • 中间的OAP：负责接收 Agent 发送的 Tracing 和Metric的数据信息，然后进行分析(Analysis Core) ，存储到外部存储器( Storage )，最终提供查询( Query )功能。
  • 左面的UI：负责提供web控制台，查看链路，查看各种指标，性能等等。
  • 右面Storage：负责数据的存储，支持多种存储类型。

搭建

服务端

下载：https://skywalking.apache.org/downloads/
image.png

解压缩：
image.png

重要的目录结构分析如下：

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

修改配置：
1、config/application.yml
这个是oap服务的配置文件，需要修改注册中心为nacos
image.png
当然也可以在启动中指定配置参数，如果没有使用本地nacos，则需要指定启动配置参数nacos.hostPort
2、webapp/webapp.yml
这个是UI服务的配置文件，其中有一个server.port配置，是UI服务的端口，默认8080，修改其他端口避免端口冲突
image.png

启动：
bin目录下进行启动

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

image.png

当然还有一个startup.bat启动文件，可以直接启动上述两个服务

浏览器访问ui端口
http://localhost:8888/，直接进入UI端
image.png

客户端

客户端就是一个微服务程序
由于Skywalking采用字节码增强技术，因此对于微服务无代码侵入，只要是普通的微服务即可，不需要引入什么依赖

只需要将微服务程序启动的时候指定我们下载的skywalking的agent包即可

  1. -javaagent:E:\Tools\skywalking-es7\oap-libs\agent\skywalking-agent.jar
  2. -Dskywalking.agent.service_name=skywalking-product-service
  3. -Dskywalking.collector.backend_service=127.0.0.1:11800
  • -javaagent：指定skywalking中的agent中的skywalking-agent.jar的路径

例如：我的下载解压路径为
【”E:\Tools\skywalking-es7\oap-libs\agent\skywalking-agent.jar”】则指定路径为该路径

  • -Dskywalking.agent.service_name：指定在skywalking中的服务名称，一般是微服务的spring.application.name
  • -Dskywalking.collector.backend_service：指定oap服务绑定的地址，oap服务默认的端口是11800，因此只需要配置为127.0.0.1:11800

可以在idea中配置启动参数即可
image.png

注意skywalking的安装路径不能存在中文，不能存在空格

启动之后可以通过网关进行访问

此时查看UI端即可查看服务已经正式启动

案例地址：

数据持久化

skywalking默认持久化的方式是存储在内存中
当然这里也是可以通过插拔方式的替换掉存储中间件，
企业中往往是使用ES存储，

mysql

修改配置文件

总共需要修改两处地方。

  • 修改默认的存储方式为mysql
  • 修改Mysql相关的信息，比如用户名、密码等

image.png

添加驱动

Skywalking的安装包中没有数据库连接驱动
将你的数据库连接驱动包放入【oap-libs】文件夹下即可
image.png

重启之后会自动建库建表

日志监控

在skywalking的UI端有一个日志的模块，用于收集客户端的日志，默认是没有数据的，那么如何将日志数据传输到skywalking中?

日志框架：log4j，logback，log4j2
例如：logback

  • 在程序中添加日志相关框架依赖

    1. <dependency>
    2.  <groupId>org.apache.skywalking</groupId>
    3.  <artifactId>apm-toolkit-logback-1.x</artifactId>
    4.  <version>${project.release.version}</version>
    5. </dependency>

  • 添加日志框架配置文件：logback-spring.xml

  • 重启应用，日志会传输到UI中

注意：如果agent和oap服务不在同一台服务器上，需要在/agent/config/agent.config配置文件末尾添加如下配置

  2. plugin.toolkit.log.grpc.reporter.server_host=${SW_GRPC_LOG_SERVER_HOST:10.10.10.1}
  3. plugin.toolkit.log.grpc.reporter.server_port=${SW_GRPC_LOG_SERVER_PORT:11800}
  4. plugin.toolkit.log.grpc.reporter.max_message_size=${SW_GRPC_LOG_MAX_MESSAGE_SIZE:10485760}
  5. plugin.toolkit.log.grpc.reporter.upstream_timeout=${SW_GRPC_LOG_GRPC_UPSTREAM_TIMEOUT:30}
  • plugin.toolkit.log.grpc.reporter.server_host：指定要向其报告日志数据的grpc服务器主机
  • plugin.toolkit.log.grpc.reporter.server_port：指定要向其报告日志数据的grpc服务器端口
  • plugin.toolkit.log.grpc.reporter.max_message_size：指定grpc客户端日职报告的最大大小
  • plugin.toolkit.log.grpc.reporter.upstream_timeout：客户端发送数据超时时间（秒）
  • plugin.toolkit.log.transmit_formatted：是否以格式化或未格式化的格式传输数据，默认TRUE

监控告警

对于服务的异常信息，比如接口有较长延迟，skywalking也做出了告警功能

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

  • 最近3分钟内服务的平均响应时间超过1秒
  • 最近2分钟服务成功率低于80%
  • 最近3分钟90%服务响应时间超过1秒
  • 最近2分钟内服务实例的平均响应时间超过1秒

当然除了以上四种，随着Skywalking不断迭代也会新增其他规则，这些规则的配置在config/alarm-settings.yml配置文件中

附录：

代码地址：https://gitee.com/zukxupu/java-cloud/blob/master/spring-middleware/skywalking/