赞
踩
又是一个意味深长的夜晚,本来今天晚上的规划是把SkyWalking的性能剖析搞一下的,然后弄一下公司的项目,没想到弄SkyWalking性能剖析还挺顺利的,把核心问题找到了,然后搞得太投入了,就顺着SkyWalking弄,这不就弄到了SkyWalking告警这玩意!这个告警其实特别简单,如下!
配置文件
SkyWalking告警配置提供两个模板,一个是系统中正在使用的,另一个是一些常用模板,如下图!
配置文件介绍
alarm-settings.yml
:当前使用的
alarm-settings-sample.yml
:常用模板
alarm-settings.yml
SkyWalking 的发行版都会默认提供config/alarm-settings.yml文件,里面预先定义了一些常用的告警规则。如下:
1.过去3分钟内服务平均响应时间超过1秒
2. 服务成功率在过去2分钟内低于80%
3.服务90%响应时间在过去3分钟内低于1000毫秒
4.服务实例在过去2分钟内的平均响应时间超过1秒
5. 端点平均响应时间过去2分钟超过1秒
这些就是警告处罚的规则,满足这些定义的规则,那么就会触发警告,然后上报,如下图!
Webhook可以简单理解为是一种Web层面的回调机制,通常由一些事件触发,与代码中的事件回调类似,只不过是Web层面的。由于是Web层面的,所以当事件发生时,回调的不再是代码中的方法或函数,而是服务接口。例如,在告警这个场景,告警就是一个事件。当该事件发生时,SkyWalking就会主动去调用一个配置好的接口,该接口就是所谓的Webhook。
Webhook回调通知
这个配置就比较简单了,alarm-settings.yml配置文件拉倒最下面!
当满足触发警告规则后,那么就会调用这里配置的接口!都会调用!
回调请求详情
SkyWalking的告警消息会通过 HTTP 请求进行发送,请求方法为 POST,Content-Type 为
application/json,其JSON 数据实基于
[{ "scopeId": 1, "scope": "SERVICE", "name": "serviceA", "id0": 12, "id1": 0, "ruleName": "service_resp_time_rule", "alarmMessage": "alarmMessage xxxx", "startTime": 1560524171000 }, { "scopeId": 1, "scope": "SERVICE", "name": "serviceB", "id0": 23, "id1": 0, "ruleName": "service_resp_time_rule", "alarmMessage": "alarmMessage yyy", "startTime": 1560524171000 }]
字段说明:
回调接口编写
@PostMapping(value = "/skyWalking/webhook")
public R skyWalking(@RequestBody List<Map<String, Object>> webhookInfo) {
log.info("auth-----webhookInfo===>"+webhookInfo);
log.info("auth===>"+"sentinelTest");
return R.success("auth---sentinelTest");
}
当然这里的List中也可以自己根据字段建实体类。
接口写好后最好在SkyWalking部署的服务器上curl一下回调接口,看请求是否能通!当然这个回调可以有高阶玩法,就是加个邮箱推送!这个不管是自己写还是直接使用别人封装好的都行,这个我就不过多扩展了!
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。