上一篇我们掌握了基于 Sleuth+Zipkin 对微服务架构实施基于日志的链路追踪,通过 Sleuth 在微服务应用中附加链路数据,再通过 Zipkin 实现链路数据收集与可视化,从而保证开发与运维人员在生产环境了解微服务的执行过程与具体细节,为产品运维提供了有力的保障。
本篇文章咱们还是围绕链路追踪这个话题,介绍另一款著名的链路追踪产品: SkyWalking,掌握 SkyWalking 的使用方法。
一、APM与SkyWalking
这些年随着微服务体系的不断完善,链路追踪已经不是什么新兴的概念与技术,很多厂商也提供了自己的链路追踪产品,例如 Spring Cloud Slueth、Zipkin、阿里鹰眼、大众点评 Cat、SkyWalking 等。但这些产品都有一个共同的名字:APM(Application Performance Management),即应用性能管理系统。顾名思义这些产品的根本目的就是对应用程序单点性能与整个分布式应用进行监控,记录每一个环节程序执行状况,通过图表与报表的形式让运维人员随时掌握系统的运行状况,其中在这些著名的产品中非常推荐各位掌握 SkyWalking 这款 APM 产品,理由很简单,它在简单易用的前提下实现了比 Zipkin 功能更强大的链路追踪、同时拥有更加友好、更详细的监控项,并能自动生成可视化图表。相比 Sleuth+Zipkin 这种不同厂商间混搭组合,SkyWalking 更符合国内软件业的“一站式解决方案”的设计理念,下面咱们来了解下 SKyWalking。
SkyWalking 提供了分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。目前在 GitHub 上 SkyWaking 拥有 15.9K Star.
二、部署SkyWalking服务端和Java Agent
在了解 SkyWalking 后,我们正式进入 SkyWalking 的安装与使用吧。
1、部署SkyWalking服务端
先看一下SkyWalking架构图:
SkyWalking 同样采用客户端与服务端架构模式,SkyWalking 服务端用于接收来自 Java Agent 客户端发来的链路跟踪与指标数据,汇总统计后由 SkyWalking UI 负责展现。
SkyWalking 服务端同时支持 gRPC 与 HTTP 两种上报方式。其中 gRPC 默认监听服务器 11800 端口,HTTP 默认监听 12800 端口,而 SKyWalking UI 应用则默认监听 8080 端口,这三个端口在生产环境下要在防火墙做放行配置。
在存储层面,SkyWalking 底层支持 ElasticSearch 、MySQL、H2等多种数据源,官方优先推荐使用 ElasticSearch,如果此时你不会 ElasticSearch 也没关系,按文中步骤操作也能完成部署。
(1)安装ElasticSearch全文搜索引擎
ElasticSearch 简称 ES,是业内最著名的全文检索引擎,常用于构建站内搜索引擎,SkyWalking 官方推荐使用 ES 作为数据存储组件。这里直接访问 ES 官网下载页:
下载后会得到 elasticsearch-7.10.2-windows-x86_64.zip 文件,解压缩后无须任何修改直接运行 bin/elasticsearch.bat 文件,如果是 Linux 系统则运行 elasticsearch.sh 文件。
默认 ES 监听 9200 与 9300 端口,其中 9200 是 ES 对外提供服务的端口;9300 是 ES 进行集群间通信与数据传输的端口,需要确保这两个端口没有被占用。
(2)下载SkyWalking
访问官网,下载最新版 SkyWalking 8.3.0,注意版本选择 v8.3.0 for ES7。
下载完毕,解压缩文件得到 apache-skywalking-apm-bin-es7 目录。这里有个重要细节,SkyWalking 路径不要包含任何中文、特殊字符甚至是空格,否则启动时会报“找不到模板文件”的异常。
(3)配置SkyWalking数据源
SKyWalking 收集到的数据要被存储在 ElasticSearch 中,因此需要指定数据源。在 config 目录下找到 application.yml,这是 SkyWalking 的核心配置文件。
在配置文件 103 行附近可以看到 storage 配置片段。
storage:
selector: ${SW_STORAGE:h2}
elasticsearch: #ES6配置
...
elasticsearch7: #ES7配置
nameSpace: ${SW_NAMESPACE:""}
clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:localhost:9200}
protocol: ${SW_STORAGE_ES_HTTP_PROTOCOL:"http"}
...
默认 SkyWalking 采用内置 H2 数据库存储监控数据,现在需要改为 elasticsearch7,这样就完成了数据源存储的切换,在启动时 SkyWalking 会自动初始化 ES 的索引。
- 修改前:
selector: ${SW_STORAGE:h2}
- 修改后:
selector: ${SW_STORAGE:elasticsearch7}
到这里,SkyWalking 数据源配置成功。
(4)启动SkyWalking应用
在 bin 目录下找到 startup.bat 运行,如果是 Linux 系统运行 startup.sh。
启动后会产生两个 Java 进程:
-
Skywalking-Collector 是数据收集服务,默认监听 11800(gRPC)与 12800(HTTP) 端口。
-
Skywalking-Webapp 是 SkyWalking UI,用于展示数据,默认监听 8080 端口。
启动成功后,访问localhost:8080/,如果看到 SkyWalking UI 首页,则说明服务端配置成功。
到这里,SkyWalking 服务端启动完毕,下面咱们来看看如何通过 SkyWalking Java Agent 上报链路数据。
2、部署SkyWalking Java Agent
我们在前面也提到,SkyWalking 可以在不修改应用源码的前提下,无侵入的实现链路追踪与 JVM 指标监控,它是怎么做到的?
这里涉及一个 Java的一个特性:Java Agent 探针技术。
Java Agent 探针说白了就是 Java 提供的一种“外挂”技术,允许在应用开发的时候在通过启动时增加 javaagent 参数来外挂一些额外的程序。
Java Agent 并不复杂,其扩展类有这严格的规范,必须创建名为 premain 的方法,该方法将在目标应用 main 方法前执行,下面就是最简单的 Java Agent 扩展类。
public class SimpleAgent {
public static void premain(String agentArgs, Instrumentation inst) {
System.out.println("=========开始执行premain============");
}
}
要完成 Java Agent,还需要提供正确的 MANIFEST.MF,以便 JVM 能够选择正确的类。在 META-INF 目录下找到 MANIFEST.MF 文件:
Manifest-Version: 1.0
Premain-Class: com.example.agent.SimpleAgent
之后我们将这个类打包为 agent.jar,假设原始应用为 test.jar,在 test.jar 启动时需要在额外附加 javaagent 参数,如下所示:
java -javaagent:agent.jar -jar test.jar
在应用启动时 Java 控制台会输出如下日志。
=========开始执行 premain============
....
通过结果会发现 java agent 在目标应用main执行前先执行了premain,实现了不修改源码的前提下增加了新的功能。
SkyWalking 也是利用 Java Agent 的特性,在 premain 中通过字节码增强技术对目标方法进行扩展,当目标方法执行时自动收集链路追踪及监控数据并发往 SkyWalking 服务端。
下面咱们来看看如何加载并使用 SkyWalking Java Agent,我们还是以实例进行讲解,因为 Java Agent 是无侵入的,并不需要源码,这里我们根据调用关系图来了解一下。
用户访问 a 服务的 a 接口,a 服务通过 OpenFeign 远程调用 b 服务的 b 接口,b 服务通过 OpenFeign 调用 c 服务的 c 接口,最后 c 接口通过 JDBC 将业务数据存储到 MySQL 数据库。
基于以上的调用链路,我们来看一下SkyWalking Java Agent的用法:在 skywalking 的 agent 目录下存在 skywalking-agent.jar,这就是 skywalking 提供的 Java Agent 扩展类(大家可自行生成测试jar文件)。
如果是生产环境下在启动应用时附加 javaagent 参数即可。
- a服务启动命令:
java -javaagent:D:\apache-skywalking-apm-bin-es7\agent\skywalking-agent.jar -Dskywalking.agent.service_name=a-service -Dskywalking.collector.backend_service=127.0.0.1:11800 -Dskywalking.logging.file_name=a-service-api.log -jar a-service.jar
- b服务启动命令:
java -javaagent:D:\apache-skywalking-apm-bin-es7\agent\skywalking-agent.jar -Dskywalking.agent.service_name=b-service -Dskywalking.collector.backend_service=127.0.0.1:11800 -Dskywalking.logging.file_name=b-service-api.log -jar b-service.jar
- c服务启动命令
java -javaagent:D:\apache-skywalking-apm-bin-es7\agent\skywalking-agent.jar -Dskywalking.agent.service_name=c-service -Dskywalking.collector.backend_service=127.0.0.1:11800 -Dskywalking.logging.file_name=c-service-api.log -jar c-service.jar
如果是在 idea 开发环境运行,需要在 VM options 附加 javaagent。
三、SkyWalking常用视图
服务启动后,我们使用postman对接口a模拟10000次用户访问,看看SkyWalking UI中产生了哪些变化:
此时访问localhost:8080/,打开 SKyWalking UI,默认显示全局的应用性能,服务状态指数越接近 1 代表该服务运行状况越好,而高延迟端点列表则将处理延迟高的 API 端点列出,这可能是我们重点排查与优化的对象。
具体指标大家可以看一下图中的注释
除了全局监控外,SkyWalking 链路追踪的展示也非常友好,点击“拓扑”按钮可以查看访问拓扑图。服务间依赖关系一目了然。
除此之外,链路追踪的展示也非常强大,服务间的 API 调用关系与执行时间、调用状态清晰列出,而且因为 SkyWalking 是方法层面上的扩展,会提供更加详细的方法间的调用过程。
SkyWalking 基于 Java Agent 对数据库的运行指标也进行收集,点击"database"便进入数据库指标监控。
看到这里,我们已经完成了SkyWalking的安装部署与应用接入。同时也介绍了部分图表的使用。当然 SKyWalking 也不是全能的,在生产环境下 SkyWalking 还需要额外考虑很多问题,如 SkyWalking 的集群管理、访问权限控制、自监控、风险预警等都要逐步完善,因此很多互联网公司也基于 SkyWalking 做二次开发以满足自身的需求。大家在使用过程中,如果有更好的实践,欢迎留言讨论。
标签:Java,service,jar,agent,最佳,Agent,监控,SkyWalking From: https://blog.csdn.net/u010223407/article/details/137631145文章将持续更新,欢迎关注公众号:服务端技术精选。欢迎点赞、关注、转发。