一、什么是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.skywalking</groupId>
<artifactId>apm-toolkit-logback-1.x</artifactId>
<version>8.12.0</version>
</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%n</Pattern>
</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配置文件中添加这个钩子,如下图: