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

ops/2025/2/12 15:02:58/

文章目录

  • 前言
  • 一、集成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: 5message: 服务实例【{name}】在10分钟内响应时间超过1s的请求超过2次# 【数据库访问响应时间规则】  database_access_resp_time_rule:# 数据库访问响应时间超过【1000】毫秒的请求超过 1 次expression: sum(database_access_resp_time > 1000) >= 1# 每隔1分钟检测一次period: 1message: 数据库【{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: trueurls:- 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 无疑是一个值得考虑的解决方案。


http://www.ppmy.cn/ops/157794.html

相关文章

实现：多活的基础中间件

实现：多活的基础中间件

APIRouter &#xff1a; 路由分发服务 API Router 是一个 HTTP 反向代理和负载均衡器&#xff0c;部署在公有云中作为 HTTP API 流量的入口&#xff0c;它能识别 出流量的归属 shard &#xff0c;并根据 shard 将流量转发到对应的 ezone 。 API Router 支持多种路由键&am…
阅读更多...
记录docker 卡住不动了

记录docker 卡住不动了

systemctl restart docker 或者systemctl status docker 卡住不动或者卡住很久 查看系统mount数量 mount | wc -l 16490 这个数量说明系统mount 数量很大了 查看当前挂载信息&#xff1a; 使用 mount 命令查看当前系统所有挂载点信息&#xff0c;它会列出设备、挂载点、文…
阅读更多...
STM32F103C8----外部中断探秘：解锁嵌入式实时响应的关键

STM32F103C8----外部中断探秘：解锁嵌入式实时响应的关键

​​​ 一、引言 在嵌入式系统的广袤世界里&#xff0c;中断就如同一位高效的调度员&#xff0c;发挥着举足轻重的作用。想象一下&#xff0c;一个嵌入式系统就像一个繁忙的工厂&#xff0c;CPU 如同工厂里的核心工人&#xff0c;负责执行各种任务。如果没有中断机制&#x…
阅读更多...
守护进程

守护进程

什么是守护进程 守护进程&#xff0c;简单来说就是让进程脱离当前会话&#xff0c;成为孤儿进程且在后台不间断运行 服务器服务进程应该为守护进程 如何成为守护进程&#xff1f; 系统daemon接口&#xff1a; #include <unistd.h>int daemon(int nochdir, int noclose…
阅读更多...
第四期书生大模型实战营-第4关-L2G4000

第四期书生大模型实战营-第4关-L2G4000

简述多模态大模型的工作原理 多模态大模型是一种能够同时理解和生成多种类型数据&#xff08;如文本、图像、音频、视频等&#xff09;的人工智能模型。其核心工作原理可概括为以下几个关键步骤&#xff1a; 1. 多模态数据编码 模态对齐&#xff1a;将不同形式的数据&#xf…
阅读更多...
maven不能导入依赖和插件Cannot resolve plugin org.apache.maven.plugins:maven-xxx

maven不能导入依赖和插件Cannot resolve plugin org.apache.maven.plugins:maven-xxx

新建了个工程&#xff0c;新设置了一个仓库地址&#xff0c;maven导入报错&#xff1a; 连最基础的maven自带的插件都无法导入&#xff1a; Cannot resolve plugin org.apache.maven.plugins:maven-install-plugin:2.4Try to run Maven import with -U flag (force update sna…
阅读更多...
Python 面向对象（类，对象，方法，属性，魔术方法）

Python 面向对象（类，对象，方法，属性，魔术方法）

前言&#xff1a;在讲面向对象之前&#xff0c;我们先将面向过程和面向对象进行一个简单的分析比较&#xff0c;这样我们可以更好的理解与区分&#xff0c;然后我们在详细的讲解面向对象的优势。 面向过程&#xff08;Procedure-Oriented Programming&#xff0c;POP&#xff0…
阅读更多...
01docker run

01docker run

docker run 用于从镜像创建并启动容器。下面是一些常用的选项&#xff1a; -d: 让容器在后台运行&#xff0c;即以守护进程模式运行。--name: 给容器指定一个名称&#xff0c;便于识别和管理。-p: 将宿主机的端口映射到容器内的端口&#xff0c;实现网络通信。-e: 设置环境变量…
阅读更多...
最新文章

Copyright @ 2022~2023