这是我参与「掘金日新计划 · 8 月更文挑战」的第17天,点击查看活动详情
性能刨析
SkyWalking 为我们提供了 性能剖析这个功能,使用这个功能我们可以查看具体的一个请求的响应时间以及效率和下游链路调用状态(遇到相应很慢的接口时,进行监控并分析)
下面我们先创建一个任务
然后我们测试这个方法 看看性能剖析的数据
@PostMapping("/all")
@ApiOperation(notes = "用户列表", value = "用户列表")
public R all(@RequestBody ListVo listVo) throws InterruptedException {
Thread.sleep(2);
return bossUserServices.getlist(listVo);
}
并且还能进行分析,可以看到请求主要耗时时间在什么位置
我们在业务实现类上面确实沉睡了2秒
try {
TimeUnit.SECONDS.sleep(2);
}catch (Exception e){
}
生产环境中对于那些响应太慢的接口请求我们完全可以进行性能剖析并且快速定位到问题。极大的提高了调优调试的效率。
告警功能
SkyWalking 告警功能是在6.x版本之后新增的,其核心是由一组规则驱动,这些规则定义是在config/alarm-settings.yml文件中。
告警由两部分组成:
- 告警规则: 即就是触发条件(满足什么样的条件是触发)
- Webhook(网络钩子):定义告警触发时,那些服务要被通知(可以理解为触发时,可以指定一个服务去进行请求)
UI界面中也可以看到一些告警信息
在配置文件可以添加自己的规则当然 也提供了默认的规则上面我们看到的两种就是。
为方便起见,我们
alarm-setting.yml
在发行版中提供了默认值。它包括以下规则:
- 过去 3 分钟内服务平均响应时间超过 1 秒。
- 最后2分钟服务成功率低于80%。
- 过去 3 分钟内超过 1 秒的服务响应时间百分比
- 服务实例最近 2 分钟平均响应时间超过 1 秒,并且实例名称与正则表达式匹配。
- 过去 2 分钟内端点平均响应时间超过 1 秒。
- 过去 2 分钟内数据库访问平均响应时间超过 1 秒。
- 过去 2 分钟内端点关系平均响应时间超过 1 秒。
rules:
# Rule unique name, must be ended with `_rule`.
service_resp_time_rule: ##
metrics-name: service_resp_time
op: ">"
threshold: 1000 ##1000ms
period: 10
count: 3
silence-period: 5 ##检查次数
message: Response time of service {name} is more than 1000ms in 3 minutes of last 10 minutes.
webhooks:
#可以通知任意 地址进行通知
# - http://127.0.0.1/notify/
Webhook 要求对等点是 Web 容器。application/json警报消息将按内容类型通过 HTTP post 发送。JSON 格式基于List<org.apache.skywalking.oap.server.core.alarm.AlarmMessage>以下关键信息:
- 范围标识,范围。所有范围都定义在
org.apache.skywalking.oap.server.core.source.DefaultScopeDefine. - 名字。目标范围实体名称。请遵循实体名称定义。
- id0。与名称匹配的范围实体的 ID。使用关系范围时,它是源实体 ID。
- 身份证1。使用关系范围时,它是目标实体 ID。否则,它是空的。
- 规则名称。中配置的规则名称
alarm-settings.yml。 - 报警信息。报警短信。
- 开始时间。以毫秒为单位测量的警报时间,发生在当前时间和 1970 年 1 月 1 日 UTC 午夜之间。
- 标签。中配置的标签
alarm-settings.yml。
具体的规则这里就不详细说明了当然他还是支持顶顶、微信、飞书等钩子,官方文档
实践是检验真理的唯一准则,感兴趣的可以去试试呀!明天见咯 😃😃😃😃