SkyWalking10.1.0实战：从零构建全链路监控，解锁微服务性能优化新境界

文章目录 前言一、集成SkyWalking二、SkyWalking使用三、SkyWalking性能剖析四、SkyWalking 告警推送4.1 配置告警规则4.2 配置告警通知地址4.3 下发告警信息4.4 测试告警4.5 慢SQL查询 总结

前言

在传统监控系统中，我们通过进程监控和日志分析来发现系统问题，但通常只能知道哪些服务出故障，而无法迅速定位具体原因。开发和运维人员需要手动查看日志或直接访问服务器，排查过程耗时且低效。而且，即使发现问题，也难以追溯到根本原因，导致解决过程反复。为此，基于分布式追踪的 APM 系统应运而生，帮助快速精准地定位问题，提升系统的可靠性和维护效率。

项目：MicroAdmin后台 账号密码：admin / admin

一、集成SkyWalking

SkyWalking 在 Java 语言中的接入方式采用 字节码增强（Bytecode Instrumentation）技术，属于无代码侵入（No Code Intrusion） 的 APM（应用性能监控）方案。 它通过 Java Agent 机制，在应用启动时动态植入字节码，无需修改业务代码，即可实现全链路追踪、调用链分析、性能监控等功能。

在需要监控的项目中增加JVM的启动参数，本地开发，在IDEA中设置如下：

添加JVM参数：

-javaagent:D:\soft\skywalking\apache-skywalking-apm-bin\agent\skywalking-agent.jar -Dskywalking.agent.service_name=micro-dev::micro-system -Dskywalking.collector.backend_service=127.0.0.1:11800

参数说明：

-javaagent:skywalking-agent.jar所在路径

-Dskywalking.agent.service_name=分组 + 微服务的服务名称（就是配置参数spring.application.name）

-Dskywalking.collector.backend_service=不用修改（日志收集地址的，固定端口11800）

启动项目：

项目启动成功之后，查看skywalking监控界面，如下：

登录系统，随便访问几个API接口，可以看到SkyWalking采集到了信息，说明我们的监控链路配置成功了。

二、SkyWalking使用

SkyWalking整个监控项、指标太多，就不一一说明，这里我们来追踪一个异常方法，以此来演示一下SkyWalking的强大功能。

在新增角色的时候，写了这样的一个异常代码，睡眠5s，被除数为0：

此时我们多次请求新增角色的接口，毋庸置疑新增肯定是失败的，这才是我们要的结果，目的就是借助SkyWalking排查错误，熟悉SkyWalking核心参数，能够熟练排查我们的线上系统异常问题，在SkyWalking监控中我们可以看到整个服务的评分以及调用成功率在下降。

核心参数说明：

Service Apdex（数字）:当前服务的评分 Successful Rate（数字）：请求成功率 Load (calls / min) 数字: 每分钟访问次数 Latency(ms)： 百分比响应延时

点击该服务进入到服务内部监控界面如下：

核心参数说明：

Service Avg Response Times（ms）：平均响应延时，单位ms Service Apdex（折线图）：一段时间内Apdex评分 Service Response Time Percentile (ms)折线图：服务响应时间百分比 Service Load (calls / min) 折线图: 分钟请求数 Success Rate (%)折线图：分钟请求成功百分比 Message Queue Consuming Count(折线图)：消息队列消耗计数 Message Queue Avg Consuming Latency (ms)折线图：消息队列平均消耗延迟（毫秒） Service Instances Load (calls / min)：节点请求次数 Slow Service Instance (ms)：每个服务实例(物理机、云主机、pod)的最大延时 Service Instance Success Rate (%)：每个服务实例的请求成功率 Endpoint Load in Current Service (calls / min)：每个端点(URL)的请求次数 Slow Endpoints in Current Service (ms)：当前端点(URL)的最慢响应时间 Endpoint Success Rate in Current Service (%)：当前端点(URL)的成功响应请求占比

仔细看这两个参数的数值：

请求成功率为0，并且最慢响应时间最大，能够很直观看到我们的接口情况。

然后我们再点击链路查看接口请求情况：

左侧：api接口列表，红色-异常请求，蓝色-正常请求 右侧：api追踪列表，api请求连接各端点的先后顺序和时间

可以看到该接口请求爆红，失败了，点击爆红的接口，可以看到错误的日志信息：

三、SkyWalking性能剖析

还是以上面的接口为例子，上面我们通过SkyWalking分析出来了，接口错误的原因：

ava.lang.ArithmeticException: / by zero 错误表示在代码中尝试进行除法运算时，除数为零。Java 中不允许任何数除以零，因为这是一个数学上的未定义操作，所以会抛出 ArithmeticException 异常

回看代码，我们可以看到代码中还设置了睡眠5s，所以接口响应时间很长，那么怎么通过SkyWalking分析出接口耗时的具体代码呢？

在【Trace Profiling】界面，新建接口任务，然后分析，即可查到耗时的代码了。

新建任务： 最大采样数：设置为1，表示端点调用一次SkyWalking agent就能监控到，最大采样数目5表示，调用接口必须5次以上 agent才能监控到。

点击上图中的新建任务后，然后继续访问这个需要分析的url，点击接口分析，就可以看见详细的代码分析页面了。

采样追踪：

上图就是我们进行性能剖析后的结果图。从左到右分别表示：栈帧名称、该栈帧总计耗时（包含其下面所有自栈帧）、当前栈帧自身耗时和监控次数，从中我们可以看到在com.micro.system.service.impl.SysRoleServiceImpl.saveRole:94 代码处，睡眠了5s，所以才导致接口请求响应慢的问题。

四、SkyWalking 告警推送

当机器或者服务出现问题时，我们会触发告警及时通知负责人，这是企业中最常见的做法，SkyWalking 也支持告警配置。

4.1 配置告警规则

修改如下的配置文件，配置自己需要的告警规则：

修改alarm-settings.yml配置文件：

rules: # 【服务响应时间规则】 service_resp_time_rule: # 服务的响应时间超过【1000】毫秒的请求超过 3 次 expression: sum(service_resp_time > 1000) >= 3 # 每隔1分钟检测一次 period: 1 # 设置3分钟内容相同告警，不重复告警 silence-period: 3 # 配置告警信息 message: 服务【{name}】在1分钟内响应时间超过1s的请求超过3次 # 【服务响应成功率SLA规则】 service_sla_rule: # 服务的响应成功率低于80%的次数 expression: sum(service_sla < 8000) >= 1 # 每隔10分钟检测一次 period: 10 # 设置3分钟内容相同告警，不重复告警 silence-period: 3 # 配置告警信息 message: 服务【{name}】在10分钟内成功率低于80%的情况发生了1次 # 【 服务响应时间的不同分位数规则】 #service_resp_time_percentile_rule: # 分位数超过【1000】毫秒的个数超过3个 #expression: sum(service_percentile{p='50,75,90,95,99'} > 1000) >= 3 # 每隔10分钟检测一次 #period: 10 # 设置5分钟内容相同告警，不重复告警 #silence-period: 5 #message: 服务【{name}】在10分钟内分位数【请求响应时间低于：50%、75%、90%、95%、99%】超过1s的请求个数超过3个 # 【单个服务实例响应时间规则】 service_instance_resp_time_rule: # 服务实例的响应时间超过【1000】毫秒的请求超过 2 次 expression: sum(service_instance_resp_time > 1000) >= 2 # 每隔10分钟检测一次 period: 10 # 设置5分钟内容相同告警，不重复告警 silence-period: 5 message: 服务实例【{name}】在10分钟内响应时间超过1s的请求超过2次 # 【数据库访问响应时间规则】 database_access_resp_time_rule: # 数据库访问响应时间超过【1000】毫秒的请求超过 1 次 expression: sum(database_access_resp_time > 1000) >= 1 # 每隔1分钟检测一次 period: 1 message: 数据库【{name}】在1分钟内响应时间超过10ms的请求超过1次 # 【端点关系响应时间规则】 endpoint_relation_resp_time_rule: # 端点调用的响应时间超过【1000】毫秒的请求超过 2 次 expression: sum(endpoint_relation_resp_time > 1000) >= 2 # 每隔10分钟检测一次 period: 10 # 配置告警信息 message: 接口【{name}】在10分钟内响应时间超过1s的请求超过2次 4.2 配置告警通知地址

修改alarm-settings.yml配置文件：

hooks: webhook: default: is-default: true urls: - http://127.0.0.1:9092/alarm/notify 4.3 下发告警信息

由于我配置的告警通知地址是项目的接口地址，这样方便我将告警信息投放到不同的接收方，如QQ邮箱，企业微信、微信等等，我这里是将告警信息发给 企业微信机器人。

4.4 测试告警

还是以我们的新增角色接口为例子，多次请求之后，接口响应慢，服务请求成功率下降，都会触发告警。

查看SkyWalking监控控制台情况：

4.5 慢SQL查询

在生产环境中，我们经常会遇到一些慢SQL，也可以通过SkyWalking监控查到，如下慢SQL耗时情况，方便我们优化SQL，特别方便。

总结

SkyWalking 是一款功能强大且易于集成的 APM 工具，适合用于微服务架构下的性能监控、故障诊断和优化。通过其强大的分布式追踪、性能分析、错误监控等功能，我们能够深入了解应用的运行状态，定位问题并进行针对性的优化。

优点：

易于集成：支持多种语言的 Agent，Java、Node.js、PHP 等都可以方便地集成。实时监控：可以实时查看服务性能、请求链路、数据库查询等信息，帮助及时发现和解决问题。强大的可视化功能：UI 展示清晰易懂，拓扑图和链路分析非常有帮助。

不足：

配置复杂：对于初次使用者来说，配置可能较为繁琐，尤其是在集群部署时，需要关注各组件之间的协调。资源消耗：SkyWalking 的后端服务（特别是 Elasticsearch）对资源有一定要求，在大规模部署时可能需要适当扩展，所以一般企业项目线上都不集成SkyWalking 日志采集。

总的来说，SkyWalking 是一个强大的监控工具，能够为微服务架构提供精准的性能和故障诊断。如果你正在使用微服务或云原生架构，SkyWalking 无疑是一个值得考虑的解决方案。