Skywalking介绍
Skywalking是一个国产的开源框架,2015年有吴晟个人开源,2017年加入Apache孵化器,国人开源的产品,主要开发人员来自于华为,2019年4月17日Apache董事会批准SkyWalking成为顶级项目,支持Java、.Net、NodeJs
等探针,数据存储支持Mysql、Elasticsearch等,跟Pinpoint一样采用字节码注入的方式实现代码的无侵入,探针采集数据粒度粗,但性能表现优秀,且对云原生支持,目前增长势头强劲,社区活跃
使用版本
当前使用版本信息为:apache-skywalking-apm-es7-8.7.0
数据存储方式
Skywalking
默认使用的是H2
,本次实战主要使用的ElasticSearch
来存储相对应的链路数据。Skywalking
本身还支持mysql、tidb、influxdb、postgresql
等数据存储方式
Skywalking的安装以及使用
安装及运行(本次安装主要是在windows)
- 下载对应的二进制软件包
(apache-skywalking-apm-es7-8.7.0.tar)
,并且解压到指定的文件夹下面 - 涉及到的主要目录为:
bin(存放对应的命令)、config(相关的配置文件)、agent(代理jar包)
- 进入bin目录直接执行目录下对应的
startup.bat
即可运行Skywalking
,默认是运行在8080端口;启动成功后即可在浏览器输入地址即可访问:127.0.0.1:8080
。运行界面如图所示: - 首次访问没有上图相关的图示数据,因为还未对项目进行代理做数据采集
运行SpringBoot
项目,并对其进行监控
运行其要进行监控的项目,增加代理参数,代理参数如下:
java -jar -javaagent:H:\apache-skywalking-apm-bin-es7\agent\skywalking-agent.jar -DSW_AGENT_NAME=demo -DSW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800
启动完项目后,就可以在SkyWalking看到该项目对应的访问数据以及对应的拓扑图
采集数据持久化
-
Skywalking
默认是通过H2对采集数据进行存取的,并且没有做相对应的持久化,相关配置在config
文件夹中application.xml
文件中的121行:selector: ${SW_STORAGE:H2}
。为了方便以及做持久化本实战主要将数据存放在ElasticSearch
中 -
修改数据存取方式为
elasticsearch7
,只需要将selector修改为对应的elasticsearch7即可:selector: ${SW_STORAGE:elasticsearch7}
-
配置elasticsearch:
nameSpace: ${SW_NAMESPACE:"elasticsearch"} //一定为要和elasticsearch中的cluster_name相对应 clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:localhost:9200}
-
重启SkyWalking之后,后期采集数据就存放在了ElasticSearch中了
注:在使用elasticsearch时需要注意其版本号,负责SkyWalking Collect将启动失败,本实战其对应的版本为7.2.0
加入日志采集
1、引入日志采集相关的jar包:
<dependency>
<groupId>org.apache.skywalking</groupId>
<artifactId>apm-toolkit-trace</artifactId>
<version>8.10.0</version>
</dependency>
<dependency>
<groupId>org.apache.skywalking</groupId>
<artifactId>apm-toolkit-logback-1.x</artifactId>
<version>8.5.0</version>
</dependency>
2、在项目resource目录下新建logback.xml
文件
<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="10 seconds">
<property name="logData" value="./logDatas" />
<property name="appName" value="accessLog" />
<statusListener class="ch.qos.logback.core.status.NopStatusListener" />
<appender name="CONSOLE_OUT" class="ch.qos.logback.core.ConsoleAppender">
<layout class="ch.qos.logback.classic.PatternLayout">
<pattern>%-15(%d{HH:mm:ss.SSS}) %msg%n</pattern>
</layout>
</appender>
<appender name="LOG_DEMO" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${logData}/logDataDemo.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
<!-- 指定生成日志保存地址 -->
<fileNamePattern>${logData}/%d{yyyy-MM-dd}/${appName}-info.%d{yyyy-MM-dd}.%i.log</fileNamePattern>
<maxFileSize>1MB</maxFileSize>
<maxHistory>30</maxHistory>
</rollingPolicy>
<encoder>
<pattern>
%-15(%d{yyyy-MM-dd HH:mm:ss} [info]) %msg%n
</pattern>
<charset>UTF-8</charset>
</encoder>
</appender>
<appender name="msystem-log" class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.log.GRPCLogClientAppender">
<!-- 日志输出编码 -->
<encoder>
<!--格式化输出:%d表示日期,%thread表示线程名,%-5level:级别从左显示5个字符宽度%msg:日志消息,%n是换行符-->
<pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{50} - %msg%n
</pattern>
</encoder>
</appender>
<root level="info">
<appender-ref ref="CONSOLE_OUT" />
</root>
<!--输出到指定日志文件-->
<logger name="outToFile" level="INFO" additivity="false">
<appender-ref ref="LOG_DEMO"/>
<appender-ref ref="msystem-log"/>
</logger>
</configuration>
3、重新启动对应的SpringBoot项目,然后访问对应的路径即可收集到相关的数据
也可以在其追踪数据中查看起对应的日志
对某个接口/端点增加性能剖析,从而找出系统瓶颈
1、增加对应的端点对应进行性能剖析(故意对log/test2方法中sleep
4秒)
@GetMapping("/test2")
public Result<ArrayList<Map<String, Object>>> test2() throws InterruptedException {
final ArrayList<Map<String, Object>> maps = new ArrayList<>();
Thread.sleep(4000);
maps.add(new HashMap<String,Object>() {{
put("name","张三");
put("age",12);
}});
maps.add(new HashMap<String,Object>() {{
put("name","李四");
put("age",32);
}});
return Result.success(maps);
}
2、访问起对应的地址(http://127.0.0.1:8802/demo/log/test2?name=1&age=12&sex=1),在收集期间,尽量多访问几次,访问次数少有可能无法采集到
3、查看相应的分析报告,从而找出具体瓶颈
点击分析就会出现如下图所示信息
通过分析可以看出耗时的主要控制器和方法,以及对应的行号
全链路栗子
1、上述实例中并未涉及到对应的数据库和redis以及其他的服务交互,所以在拓扑图中看到的数据是非常单一的
2、如果在应用中有数据库、redis以及其他服务的调用在起拓扑图中会清晰的看到具体的调用关系,实例如下图:
3、当其中一个服务不可用时,其拓扑图会标识某个业务为不健康的(红色),下图是因为手动关闭了redis的服务
4、接口请求异常会在相对应的追踪页面看到红色标注的信息,通过点击查看日志可以看到报错信息