网站后台验证码错误,十大少儿编程教育品牌,汕尾英文网站建设,个人建站怎么做网站好文章目录 前言一、集成SkyWalking二、SkyWalking使用三、SkyWalking性能剖析四、SkyWalking 告警推送4.1 配置告警规则4.2 配置告警通知地址4.3 下发告警信息4.4 测试告警4.5 慢SQL查询 总结 前言
在传统监控系统中#xff0c;我们通过进程监控和日志分析来发现系统问题… 文章目录 前言一、集成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_namemicro-dev::micro-system -Dskywalking.collector.backend_service127.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 Timesms平均响应延时单位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{p50,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/notify4.3 下发告警信息
由于我配置的告警通知地址是项目的接口地址这样方便我将告警信息投放到不同的接收方如QQ邮箱企业微信、微信等等我这里是将告警信息发给 企业微信机器人。 4.4 测试告警
还是以我们的新增角色接口为例子多次请求之后接口响应慢服务请求成功率下降都会触发告警。 查看SkyWalking监控控制台情况 4.5 慢SQL查询
在生产环境中我们经常会遇到一些慢SQL也可以通过SkyWalking监控查到如下慢SQL耗时情况方便我们优化SQL特别方便。 总结
SkyWalking 是一款功能强大且易于集成的 APM 工具适合用于微服务架构下的性能监控、故障诊断和优化。通过其强大的分布式追踪、性能分析、错误监控等功能我们能够深入了解应用的运行状态定位问题并进行针对性的优化。
优点
易于集成支持多种语言的 AgentJava、Node.js、PHP 等都可以方便地集成。实时监控可以实时查看服务性能、请求链路、数据库查询等信息帮助及时发现和解决问题。强大的可视化功能UI 展示清晰易懂拓扑图和链路分析非常有帮助。
不足
配置复杂对于初次使用者来说配置可能较为繁琐尤其是在集群部署时需要关注各组件之间的协调。资源消耗SkyWalking 的后端服务特别是 Elasticsearch对资源有一定要求在大规模部署时可能需要适当扩展所以一般企业项目线上都不集成SkyWalking 日志采集。
总的来说SkyWalking 是一个强大的监控工具能够为微服务架构提供精准的性能和故障诊断。如果你正在使用微服务或云原生架构SkyWalking 无疑是一个值得考虑的解决方案。
