基于SkyWalking的分布式跟踪系统 - 异常告警

通过前面2篇文章我们搭建了SW的基础环境,监控了微服务,能了解所有服务的运行情况。但是当出现服务响应慢,接口耗时严重时我们需要立即定位到问题,这就需要我们今天的主角--监控告警,同时此篇也是SW系列的最后一篇。

UI参数

首先我们认识一下SW DashBoard上的几个关键参数,如下图所示

告警配置

告警流程

skywalking发送告警的基本原理是每隔一段时间轮询skywalking-collector收集到的链路追踪的数据,再根据所配置的告警规则(如服务响应时间、服务响应时间百分比)等,如果达到阈值则发送响应的告警信息。发送告警信息是以线程池异步的方式调用webhook接口完成,(具体的webhook接口可以使用者自行定义),从而开发者可以在指定的webhook接口中自行编写各种告警方式,钉钉告警、邮件告警等等。

规则配置

告警的核心由一组规则驱动,这些规则定义在 config/alarm-settings.yml,打开之后如下所示:

告警规则的定义分为两部分。

  • 告警规则。它们定义了应该如何触发度量警报,应该考虑什么条件。
  • [网络钩子](#Webhook}。当警告触发时,哪些服务终端需要被告知。

告警规则主要有以下几点

  • Rule name。 在告警信息中显示的唯一名称。必须以_rule结尾。
  • Metrics name。 也是oal脚本中的度量名。
  • Include names。 其下的实体名称都在此规则中。比如服务名,终端名。
  • Threshold。 阈值。
  • OP。 操作符, 支持?>,?<,?=。
  • Period.。 多久检查一次当前的指标数据是否符合告警规则这是一个时间窗口,与后端部署环境时间相匹配。
  • Count。 在一个Period窗口中,如果values超过Threshold值(按op),达到Count值,需要发送警报。
  • Silence period。 在时间N中触发报警后,在TN -> TN + period这个阶段不告警。 默认情况下,它和Period一样,这意味着相同的告警(在同一个Metrics name拥有相同的Id)在同一个Period内只会触发一次

Webhook

SkyWalking 的告警 Webhook 要求对等方是一个 Web 容器. 告警的消息会通过 HTTP 请求进行发送, 请求方法为?POST,?Content-Type?为?application/json, JSON 格式基于?List<org.apache.skywalking.oap.server.core.alarm.AlarmMessage, 包含以下信息.

  • scopeId. 所有可用的 Scope 请查阅?org.apache.skywalking.oap.server.core.source.DefaultScopeDefine.
  • name. 目标 Scope 的实体名称.
  • id0. Scope 实体的 ID.
  • id1. 未使用.alarmMessage. 报警消息内容.
  • startTime. 告警时间, 位于当前时间与 UTC 1920/1/1 之间.
[{
    "scopeId": 1,
        "name": "serviceA",
    "id0": 12,
    "id1": 0,
    "alarmMessage": "alarmMessage xxxx",
    "startTime": 1560524171000
}, {
    "scopeId": 1,
        "name": "serviceB",
    "id0": 23,
    "id1": 0,
    "alarmMessage": "alarmMessage yyy",
    "startTime": 1560524171000
}]

代码实战

  • 编写实体类用于接收sw告警消息
@Data
public class SwAlarmVO {
    private int scopeId;
    private String name;
    private int id0;
    private int id1;
    private String alarmMessage;
    private long startTime;
}
  • 编写webhook接口
@RestController
@RequestMapping("sw")
@Log4j2
public class AlarmController {
    @PostMapping("/alarm")
    public void alarm(@RequestBody List<SwAlarmVO> alarmList){
        log.info("skywalking alarm message:{}",alarmList);
        //todo doalarm
    }
}
  • 修改告警配置,开放webhook接口
  • 为了模拟请求调用慢,我们在代码中使用Thread.sleep(1000)增加接口耗时,然后等webhoook接口告警响应

详细信息如下:
[SwAlarmVO(scopeId = 2, name = dubbo - consumer - pid: 13812 @ jianzhang11, id0 = 28, id1 = 0, alarmMessage = Response time of service instance dubbo - consumer - pid: 13812 @ jianzhang11 is more than 1000ms in 2 minutes of last 10 minutes, startTime = 1573122018755), SwAlarmVO(scopeId = 2, name = dubbo - provider2 - pid: 14108 @ jianzhang11, id0 = 25, id1 = 0, alarmMessage = Response time of service instance dubbo - provider2 - pid: 14108 @ jianzhang11 is more than 1000ms in 2 minutes of last 10 minutes, startTime = 1573122018755)]
此时webhook能正常接收到sw的告警信息,后续的消息通知直接定制开发即可。

相关文章:

基于SkyWalking的分布式跟踪系统 - 环境搭建

基于SkyWalking的分布式跟踪系统 - 微服务监控

请关注个人公众号:JAVA日知录

原文地址:https://www.cnblogs.com/jianzh5/p/11823686.html

时间: 2024-09-30 23:02:30

基于SkyWalking的分布式跟踪系统 - 异常告警的相关文章

基于SkyWalking的分布式跟踪系统 - 微服务监控

上一篇文章我们搭建了基于SkyWalking分布式跟踪环境,今天聊聊使用SkyWalking监控我们的微服务(DUBBO) 服务案例 假设你有个订单微服务,包含以下组件 MySQL数据库分表分库(2台) 生产者(2台) dubbo-provider 消费者 dubbo-consumer 网络拓扑图如下 生产者的关键代码 @Service public class OrderServiceImpl implements OrderService { @Autowired protected Ord

微服务之分布式跟踪系统(springboot+zipkin)

微服务之分布式跟踪系统(springboot+zipkin) 一.zipkin是什么 zipkin是一个开放源代码分布式的跟踪系统,由Twitter公司开源,它致力于收集服务的定时数据,以解决微服务架构中的延迟问题,包括数据的收集.存储.查找和展现.它的理论模型来自于Google Dapper 论文. 每个服务向zipkin报告计时数据,zipkin会根据调用关系通过Zipkin UI生成依赖关系图,显示了多少跟踪请求通过每个服务,该系统让开发者可通过一个 Web 前端轻松的收集和分析数据,例如

实现一个基于WCF的分布式缓存系统

前言: 用到分布式的东西很多了,一直想做一个简单的分布式小项目练练手学习下.后来决定来一个简单的分布式缓存的系统. 在企业应用开发中缓存的用例不胜枚举,但是每次更多的是单机的部署与使用,没有对应的需求是一个原因,另一个原因总是好高骛远做过的总是不想再进行修正. 这次的分布式就从最简单的分布式缓存开始.说简单是因为没有实现分布式缓存高深的寻址,或者对备份处理的牛X实现.只是实现了“分布”这个目的,不足之处还请大家指导. 分布的实现方式有哪些? 既然做“分布”,当然要看看主流的“分布”实现方式.小弟

简述分布式跟踪系统实现原理

问题来源 互联网项目通常都是大用户量,大并发,因此从技术架构上大多采用分布式架构构建成大型分布式系统,SOA或者是微服务,一个请求涉及到多个子系统,如果某个请求的处理不正常,怎么排查定位问题呢?如果没有合适的手段,排查问题无异大海捞针,为了提高解决问题的效率,迫切需要有一个技术手段能跟踪整个处理环节,并能够快速定位.一种可行的方案就是跟踪这个调用链,把每次请求的完整处理环节串联起来,这样就可以实现对调用路径的全程监控. 技术实现要点 采用日志埋点技术,在请求的处理入口处为该次请求分配一个Trac

设计和应用分布式调用跟踪系统

分布式追踪系统dapper 分布式调用跟踪系统的设计和应用 >>为什么需要分布式调用跟踪系统 随着分布式服务架构的流行,特别是微服务等设计理念在系统中的应用,业务的调用链越来越复杂, 可以看到,随着服务的拆分,系统的模块变得越来越多,不同的模块可能由不同的团队维护, 一个请求可能会涉及到几十个服务的协同处理, 牵扯到多个团队的业务系统,那么如何快速准确的定位到线上故障?同时,缺乏一个自上而下全局的调用id,如何有效的进行相关的数据分析工作? 对于大型网站系统,如淘宝.京东等电商网站,这些问题尤

分布式服务跟踪系统

一个分布式服务跟踪系统主要由三部分构成: 数据收集 数据存储 数据展示 根据系统大小不同,每一部分的结构又有一定变化.譬如,对于大规模分布式系统,数据存储可分为实时数据和全量数据两部分,实时数据用于故障排查(Trouble Shooting),全量数据用于系统优化:数据收集除了支持平台无关和开发语言无关系统的数据收集,还包括异步数据收集(需要跟踪队列中的消息,保证调用的连贯性),以及确保更小的侵入性:数据展示又涉及到数据挖掘和分析.虽然每一部分都可能变得很复杂,但基本原理都类似. 服务追踪的追踪

Dapper,大规模分布式系统的跟踪系统--转

原文地址:http://bigbully.github.io/Dapper-translation/ 概述 当代的互联网的服务,通常都是用复杂的.大规模分布式集群来实现的.互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发.可能使用不同的编程语言来实现.有可能布在了几千台服务器,横跨多个不同的数据中心.因此,就需要一些可以帮助理解系统行为.用于分析性能问题的工具. Dapper--Google生产环境下的分布式跟踪系统,应运而生.那么我们就来介绍一个大规模集群的跟踪系统,

个推基于 Zipkin 的分布式链路追踪实践

作者:个推应用平台基础架构高级研发工程师 阿飞 01业务背景 随着微服务架构的流行,系统变得越来越复杂,单体的系统被拆成很多个模块,各个模块通过轻量级的通信协议进行通讯,相互协作,共同实现系统功能. 单体架构时,一个请求的调用链路很清晰,一般由负载均衡器将用户请求转发到后端服务,由后端服务进行业务处理,需要的数据从外部的存储中获取,处理完请求后,再经由负载均衡器返回给用户. 而在微服务架构中,一个请求往往需要多个模块共同协作处理,不同模块可能还依赖于不同的外部存储,各个模块的实现技术还不尽相同,

基于ZooKeeper的分布式Session实现(转)

1.   认识ZooKeeper ZooKeeper—— “动物园管理员”.动物园里当然有好多的动物,游客可以根据动物园提供的向导图到不同的场馆观赏各种类型的动物,而不是像走在原始丛林里,心惊胆颤的被动 物所观赏.为了让各种不同的动物呆在它们应该呆的地方,而不是相互串门,或是相互厮杀,就需要动物园管理员按照动物的各种习性加以分类和管理,这样我们才 能更加放心安全的观赏动物.回到我们企业级应用系统中,随着信息化水平的不断提高,我们的企业级系统变得越来越庞大臃肿,性能急剧下降,客户抱怨频频.拆 分系